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Foreword 


This  volume  presents  the  deliberations  and  conclusions  of  the  individual  panels  making  up  the 
2000  Air  Force  Scientific  Advisory  Board  (SAB)  Summer  Study,  “Air  Force  Command  and 
Control:  The  Path  Ahead.”  In  this  study,  the  Board  was  asked  to  assess  the  command  and 
control  system  and  the  supporting  communication  and  information  systems;  to  consider  technical 
and  process  improvements  and  to  make  recommendations  on  what  should  be  done  to  “have  the 
Air  Force  linked  by  2005”;  and  to  build  toward  the  Air  Force’s  long-term  command  and  control 
goals.  There  are  two  volumes  to  the  report.  Volume  1  presents  a  brief  summary  of  the  findings 
and  the  major  recommendations.  This  volume,  Volume  2,  presents  the  panel  reports,  including 
detailed  findings  and  recommendations. 

The  study  results  are  the  product  of  a  substantial  effort  by  a  skilled  team,  including  panels  led  by 
experts  in  their  assigned  area.  The  study  leadership  wishes  to  thank  the  many  individuals  and 
organizations  in  Government  and  industry  who  contributed  to  the  deliberations  and  conclusions 
presented.  In  addition  to  SAB  members,  many  ad  hoc  members  devoted  their  time.  Air  Force 
Major  Air  Command  liaison  officers  were  extremely  helpful  in  our  research  and  deliberations,  as 
were  the  technical  writers  provided  by  the  Air  Force  Academy.  In  addition,  both  the  liaison 
officers  and  the  technical  writers  provided  outstanding  administrative  and  logistics  support.  We 
gratefully  acknowledge  the  contributions  and  guidance  of  our  General  Officer  Participant, 
General  John  Jumper,  Commander,  Air  Combat  Command;  and  Major  General  Gerald 
Perryman,  Jr.,  Commander,  Aerospace  Command  and  Control  and  Intelligence,  Surveillance, 
and  Reconnaissance  Center. 

The  study  leaders  would  also  like  to  give  special  recognition  to  the  SAB  Secretariat  and  support 
staff,  in  particular  to  Capt  D.  Brent  Morris,  the  Study  Executive  Officer;  and  to  Ms.  Kristin 
Lynch  of  the  ANSER  team,  who  provided  invaluable  administrative  and  editing  assistance  in  the 
preparation  of  graphics  and  the  publication  of  the  report. 

We  believe  that  through  the  dedication  of  the  current  leadership,  the  Air  Force  has  the  greatest 
opportunity  ever  in  developing  an  effective  and  efficient  theater  command  and  control  system, 
and  we  encourage  every  Air  Force  member  to  seize  this  opportunity. 

Finally,  this  report  reflects  the  collective  judgment  of  the  SAB  and  hence  is  not  to  be  viewed  as 
the  official  position  of  the  United  States  Air  Force. 
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Executive  Summary 
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For  more  than  three  decades,  the  Air  Force  has  scrutinized  command  and  control  (C  ) 
modernization  planning,  programs,  training,  procedures,  and  architectures  and  has  identified 
repetitive  C  problems  in  each  decade. 

The  Air  Force  Chiefs  of  Staff  (CSAFs)  have  chartered  numerous  studies  and  conducted  four-star 
reviews  in  their  attempts  to  fix  the  Air  Force  C  problem.  These  CSAF  studies  began  with  the 
1986  Air  Force  Studies  Board  Summer  Study;  this  was,  in  turn,  followed  by  the  1992  and  1993 
Command,  Control,  Communications,  Computers,  and  Intelligence  Broad  Area  Reviews,  the 

1996  Air  Force  Scientific  Advisory  Board  (SAB)  Summer  Study,  the  1997  C2  Task  Force,  the 

1997  C2  Four-Star  Summit,  and  this  2000  SAB  C2  Summer  Study.  The  Air  Force  Chiefs  of  Staff 
also  established  a  new  Air  Staff  C"  Directorate,  an  Air  Staff  C“  General  Officer  Steering  Group, 
and  the  Aerospace  C  Intelligence,  Surveillance,  and  Reconnaissance  Center  (AC2ISRC)  in  their 
attempts  to  fix  C2. 

The  redirection  of  this  year’s  SAB  Summer  Study  from  “limited  forward  basing”  to  “command 
and  control”  reflects  the  Chief  of  Staffs  strong  desire  to  improve  Air  Force  C  capability.  Each 
study  made  recommendations  for  fixing  the  problems  the  Air  Force  was  having  with  C2. 

Analysis  of  the  recommendations  indicates  that  the  same  recommendations  were  made  many 
times,  yet  the  Service  is  not  achieving  the  vision  of  linked  Air  Force  command  centers  that  are 
able  to  collaborate  globally  in  support  of  all  commanders  in  chiefs  (CINCs),  Services,  allies,  and 
the  Aerospace  Expeditionary  Force. 

The  lessons  learned  from  DESERT  STORM  and  ALLIED  FORCE  and  the  results  of  every  SAB 
and  Defense  Science  Board  study  have  detennined  that  U.S.  aerospace  power  capabilities 
continue  to  outperform  the  associated  C2  capabilities.  In  theater  C2,  this  is  particularly  evident  in 
time-critical  targeting,  battle  damage  assessment,  and  campaign  assessments. 

The  Tasking 

The  Air  Force  is  not  on  a  path  that  provides  coherence  across  space,  air,  and  land  assets  to 
support  the  timeliest  and  effective  decision-making  and  execution.  Thus,  the  Board  was  asked  in 
the  Terms  of  Reference  (Appendix  A)  to 

•  Assess  the  C2  system  and  the  supporting  communication  and  information  systems 

•  Consider  technical  and  process  improvements  and  make  recommendations  on  what  should  be 
done  to  “have  the  Air  Force  linked  by  2005” 

•  Build  toward  the  Air  Force’s  long-term  C2  goals 

The  specific  tasks  are  shown  below;  each  task  had  a  panel  to  address  it.  Panel  membership  is  in 
Appendix  C.  The  SAB  was  to 

•  Define  the  Air  Force  C2  system  with  today’s  capabilities  and  identify  alternatives  to  enhance  C2 
over  time 

•  Define  interoperability  (joint  and  coalition)  to  ensure  coordinated  efforts  on  the  battlefield 

•  Identify  the  technologies  that  can  enhance  present  and  fiiture  C2  systems,  with  near-term 
emphasis  on  timely  and  effective  communication 
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•  Assess  the  acquisition,  programmatic,  and  cost-effectiveness  issue 

•  Consider  the  organizational,  personnel,  training,  and  support  consequences 

And  we  added  a  Bridging  and  Vision  Panel. 

A  Framework  for  Solution 

The  Study  recognized  the  many  past  organizations,  directives,  studies,  and  other  efforts  to 
develop  a  theater  C2  system  for  the  Air  Force.  Many  dedicated  and  talented  leaders  have  made 
great  efforts,  and  even  great  strides,  in  the  name  of  C  .  Yet  we  once  again  find  ourselves  on  the 
doorstep  with  a  basketful  of  comments  and  ideas  to  improve  the  C2  of  Air  Force  combat 
operations. 

It  is  our  belief  that  the  solution  set  can,  and  should,  be  cast  in  a  framework  in  order  to  capture  the 
underlying  rationale  for  the  suggestions.  Our  framework  includes  the  following  elements: 

•  A  unified,  understood,  focused  approach  to  C2 

•  A  process,  driven  by  the  concept  of  operations  and  based  on  capabilities,  that  encourages,  not 
impedes,  system  operational  enhancement 

•  Acquisition  processes  that  are  timely  and  efficient  in  capturing  emerging  technologies 

•  Taking  the  lead  in  becoming  more  interoperable,  including  joint  and  coalition  operations 

•  Horizontal  integration  of  intelligence,  surveillance,  and  reconnaissance  (ISR)  with  C2 

•  Focus  and  follow-through 

Recommendations 

We  recommend  that  the  following  actions  be  taken: 

Recommendation  1.  Emphasize  the  Role  of  Command  and  Control  in  the  Air  Force 

It  is  important  that  all  levels  of  the  Air  Force,  as  well  as  Congress  and  other  Government  entities, 
understand  the  criticality  of  effective  C  to  the  outcome  of  a  crisis. 

Recommendation  2.  Manage  Theater  Command  and  Control  as  an  Integrated  Set  of 
Weapon  Systems 

When  an  Air  Force  system  (for  example,  the  F-15E)  is  officially  designated  a  weapons  system,  a 
certain  fonnality  in  the  management  of  that  system,  including  people,  hardware,  software, 
training,  certification,  maintenance,  and  evolution,  is  established  and  implemented.  C2  systems 
deserve  nothing  less. 

Recommendation  3.  Strengthen  the  Air  Operations  Center  (AOC)  Through  Restructuring, 
Staffing,  and  Training 

Though  the  AOC  is  at  the  heart  of  precision  air  operations,  recent  conflicts  have  been 
characterized  as  a  “pickup  game”  of  equipment  and  personnel.  Consequently,  the  efficiency  and 
success  of  these  air  operations  have  suffered.  An  effective  and  efficient  AOC,  ready  to  deploy  or 
operate  from  home  at  any  time,  is  absolutely  essential. 
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Recommendation  4.  Field  and  Evolve  the  Theater  Battle  Management  Core  System 
(TBMCS) 

TBMCS  has  been  a  major,  albeit  painful,  step  to  a  new  integrated  theater  C  system.  Though  it 
cannot  be  considered  a  final  configuration  with  all  modules  in  optimum  operation,  it  is  a  major 
step  forward  from  the  previously  fragmented  system(s).  It  is  time  to  accept  the  system  and  to 
accept  the  fact  that  continual  upgrades  will  be  needed  to  meet  operational  requirements  and 
technology  advances;  the  upgrades  should  be  so  planned. 

Recommendation  5.  Institutionalize  a  C2  Evolutionary  Integration  Process 

The  major  difficulty  in  taking  advantage  of  developments  from  the  military  and  commercial 
sectors — including  off-the-shelf  solutions,  as  well  as  those  successfully  prototyped  in  laboratory 
or  field  exercises — has  been  the  lack  of  a  formal  and  cyclical  means  to  integrate  new  capabilities 
online.  The  Air  Force  should  create  and  support  a  process  for  the  evolutionary  integration  of 
developed  modules. 

Critical  to  effective  integration  and  management  is  the  creation  of  a  partnership,  based  on  mutual 
support  and  trust,  of  the  operators  (for  example,  AC2ISRC);  the  developers  (for  example,  the 
Electronic  Systems  Center  [ESC]  or  Air  Force  Research  Laboratory);  the  integrators  (for 
example,  ESC);  and  the  operational  testers  (for  example,  the  Air  Force  Operational  Test  and 
Evaluation  Center),  each  of  which  must  accept  and  carry  out  its  responsibilities. 

Recommendation  6.  Enable  and  Encourage  Rapid  Technology  Insertion 

The  Study  determined  that  there  are  no  technology  impediments  to  substantial  improvements  in 
the  effectiveness  and  efficiency  of  air  operations  C2.  With  some  exceptions,  in  which  additional 
operational  focus  is  needed,  the  emphasis  must  be  on  the  timely  and  effective  transition  of 
military  and  commercial  technologies  to  the  Air  Force  C2  system  needs.  The  Air  Force  should 
follow  a  focused  effort  to  improve  technology  exploitation.  A  C2  testbed  is  essential  to  fostering 
rapid  development  of  the  AOC  and  other  elements  of  theater  C2. 

Recommendation  7.  Achieve  Information  Interoperability  for  Warfighters  Through  the 
Joint  Battlespace  InfoSphere  (JBI) 

The  opportunity  to  significantly  improve  our  ability  to  conduct  effective  joint  and  coalition 
warfare  rests  on  the  degree  of  interoperability  of  the  C2  processes.  The  Air  Force  should  seize 
the  initiative  to  evolve  the  JBI  (see  Chapter  8)  as  the  basis  for  true  interoperability.  Many 
specific  nearer-term  problem  fixes  are  also  important  and  possible. 

Recommendation  8.  Staff  and  Train  to  Be  Consistent  With  the  Importance  of  C2 

The  Air  Force  has  been  a  pioneer  in  recognizing  the  importance  of  its  people.  At  the  heart  of  this 
recognition,  and  built  on  the  foundational  element  of  “quality  people”  for  the  Air  Force  core 
competencies,  is  the  establishment  of  a  trained  force  of  C2  professionals. 

Recommendation  9.  Strengthen  Efforts  for  Attack  of  Time-Critical  Targets 

Recent  crises  have  again  highlighted  the  shortfall  in  the  capability  for  rapid  acquisition, 
identification,  and  attack  of  mobile  targets.  Clearly,  the  delays  in  the  process  are  unacceptable, 
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and  progress  in  the  improvement  has  been  marginal.  The  Air  Force  should  establish  a  program 
team  to  address  the  rapid-response  attack  of  time-critical  targets. 

Recommendation  10.  Facilitate  and  Enhance  Data  Connectivity 

9 

Critical  to  the  dynamic  management  of  combat  airpower  is  the  data  connectivity  from  C 
activities  to  the  aircraft.  The  delays  in  fielding  solutions  to  the  aircraft  datalink  problem  seem  to 
be  more  political  than  technical.  The  Air  Force  should  exercise  leadership  in  achieving  the  goal 
of  interlinking  aircraft  based  on  operational  access  to  message  sets  (J-series)  rather  than 
emphasizing  only  specific  equipage. 

Summary 

The  essence  of  the  recommendation  set  is  to  provide  focus  and  follow-through  on  C  issues  from 
a  very  high  level.  They  key  actions  are  to 

•  Establish  a  single  C2ISR  manager  at  the  Air  Force  level  (for  example,  a  three-star  operator) — an 
Air  Force  Council  Member. 

•  Integrate  expert  information  technology  professionals  (internal  and  new)  into  the  C2  staff. 

•  Direct  a  C2  program  restructuring. 

•  Adopt  the  Global  Command  and  Control  System  (GCCS)  framework:  evolve  theater  Air  Force 
C2  applications  into  GCCS-AF. 

•  Direct  a  capability-centric  evolutionary  integration  process  for  C2 

•  Manage  theater  aerospace  C2  as  a  system  of  weapon  systems. 

•  Baseline  the  number,  configuration,  and  location  of  AOCs.  Enhance  operation  and  reduce 
personnel  through  daily  “wartime”  use. 

•  Appoint  a  “lead  dog”  for  agile  combat  support  software  systems  (Global  Combat  Support 
System- Air  Force). 

The  Air  Force  vision  of  “well-equipped  C  centers  collaborating  globally  in  support  of  the 
CINCs”  can  be  rapidly  achieved  if  senior  Air  Force  leadership  strongly  endorses  the  need  for  an 
enterprise-wide  C  capability.  The  Air  Force  must  restructure  the  way  C  programs  are  managed 
and  resourced,  and  at  every  opportunity  leadership  must  clearly  speak  out  about  their  dedication 
to  achieving  an  enterprise-wide  C  capability.  In  this  report  we  have  provided  a  proposal  for 
how  the  Air  Force  can  achieve  an  enterprise-wide  C2  capability  by  2005.  We  have  provided  our 
views  on  areas  that  the  Secretary  of  the  Air  Force,  Air  Staff,  and  major  command  staffs  should 
focus  on  in  starting  down  a  C2  modernization  journey.  The  journey  of  achieving  an  effective 
distributed,  collaborative,  enterprise-wide  C  capability  that  allows  C  centers  to  collaborate 
globally  in  support  of  the  CINCs  is  one  of  the  most  important  journeys  the  Air  Force  must  take 
in  the  2 1  st  century. 
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Chapter  1 
Introduction 


1.1  Introduction 

This  chapter  provides  the  background  and  context  for  the  Air  Force  Scientific  Advisory  Board’s 
(SAB’s)  study  on  improving  command  and  control  (C2).  Previous  studies  and  actions  to  enhance 
the  Air  Force’s  C  capability  over  time  are  reviewed  in  an  effort  to  advocate  the  view  that 
substantial  change  in  management  and  resource  allocation  is  required  to  fix  long-term 
limitations.  The  history  suggests  that,  as  an  institution,  the  Air  Force  has  not  found  an  effective 
way  to  change  the  system.  The  value  of  C2  is  discussed  to  persuade  the  reader  that  greater 
importance  must  be  accorded  C2  as  a  weapon  system.  There  has  been  considerable  debate  about 
intelligence,  surveillance,  and  reconnaissance  (ISR)  as  a  part  of  C2.  The  study  team  considers 
ISR  an  essential  element  of  operational  and  tactical  C  .  This  chapter  describes  how  the  Theater 
Command  and  Control  System  fits  into  the  overall  C2  capability.  Finally,  the  chapter  advocates 
the  need  for  the  management  of  combat  information  to  reduce  the  burden  on  the  warfighter,  who 
is  so  increasingly  overloaded  with  information  that  it  is  difficult  to  find  what  is  needed. 

Volume  1  presented  the  summary  of  the  study  findings  and  a  brief  recap  of  the  key 
recommendations.  This  volume,  Volume  2,  provides  the  detailed  reports  of  the  panels,  including 
their  charter,  approach,  and  visit  and  briefing  trail.  Each  panel’s  chapter  provides  a  more 
extensive  set  of  recommendations. 

1.2  History — “Lessons  Learned” 

For  more  than  three  decades,  the  Air  Force  has  scrutinized  C  modernization  planning,  programs, 
training,  procedures,  and  architectures  and  has  identified  repetitive  C  problems  in  each  decade. 
There  have  been  many  failed  attempts  in  the  1970s,  1980s,  and  1990s  to  fix  these  repetitive 
problems  and  this  SAB  Summer  Study  in  2000  kicks  off  the  fourth  decade  of  analysis  in  finding 
the  needed  fixes. 
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The  redirection  of  this  year’s  SAB  Summer  Study  topic  from  limited  forward  basing  to  C 
reflects  the  Chief  of  Staffs  continuing  concern  about  improving  Air  Force  C2  capability.  Each 
study  made  recommendations  for  fixing  the  problems  the  Air  Force  was  having  with  C2. 

Analysis  of  study  recommendations  indicates  that  the  same  recommendations  were  made  many 
times,  yet  the  Service  is  not  achieving  the  vision  of  Air  Force  command  centers  that  are  linked 
and  have  the  ability  to  collaborate  globally  in  support  of  all  commanders  in  chiefs  (CINCs), 
Services,  allies,  and  the  Aerospace  Expeditionary  Force. 

The  lessons  learned  from  DESERT  STORM  and  ALLIED  FORCE  and  the  results  of  past  Air 
Force  SAB  and  Defense  Science  Board  studies  have  determined  that  U.S.  aerospace  power 
capabilities  continue  to  outperform  the  associated  C  capabilities.  This  is  particularly  evident  in 
theater  C2  of  time-critical  targeting,  battle  damage  assessment,  and  campaign  assessments. 

1.3  C2  and  the  Theater  Aerospace  Command  and  Control  System  (TACCS) 

TACCS  is  only  one  part  of  the  overall  joint  C  capability  of  the  Department  of  Defense.  CINCs 
of  the  regional  and  functional  commands  each  have  C2  systems.  TACCS  defines  the  capability 
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to  support  a  Joint  Forces  Commander  and  the  Joint  Forces  Air  Component  Commander  in  daily, 
crisis,  or  combat  operations.  TACCS  must  interface  with  other  component  commanders  and 
specifically  with  Space  Command,  Special  Operations  Command,  and  Transportation  Command 
C  systems.  This  study  includes  assessment  and  recommendations  for  improving  all  Air  Force 
C2  capability  but  focuses  on  theater  C2  as  reflected  in  the  terms  of  reference. 

1.4  The  Value  of  Theater  Command  and  Control 

Theater  C  is  defined  as  the  processes  and  systems  that  the  commander  uses  to  develop  the 
strategy,  to  plan  operations,  to  control  execution,  and  to  assess  the  effects  in  crisis  or  combat. 
While  the  well-defined  principles  of  C  remain  valid,  the  rapid  improvements  in  combat  aircraft 
and  sensor  capabilities  are  driving  the  need  for  more  rapid  decision-making  processes.  New 
concepts  of  operations — including  effects-based  warfare,  precision  strike,  and  flex  targeting  to 
attack  moving  or  movable  targets — all  require  integration  and  synchronization  of  larger  and 
diverse  forces. 

Commanders  need  to  optimize  force  application  to  rapidly  achieve  objectives  and  end  the 
conflict  quickly.  Enhancing  C2  means  reducing  the  decision  cycle  time  to  significantly  shorter 
timelines  than  the  adversary’s.  This  enables  the  commander  to  dynamically  gain  the  initiative 
and  respond  to  opportunities.  The  key  elements  of  dynamic  C2  are  knowledge  of  the  adversary, 
real-time  knowledge  of  the  battlespace,  distributed  knowledge  of  the  commander’s  intent, 
decentralized  execution,  dynamic  control  of  sensors  and  shooters,  and  real-time  assessment  of 
effects.  C  must  be  improved  in  order  to  improve  our  force  effectiveness  today  and  to  be 
prepared  to  exploit  the  capabilities  of  our  future  forces  such  as  the  F-22,  the  Joint  Strike  Fighter, 
the  airborne  laser,  and  other  systems. 

1.5  ISR  in  Command  and  Control 

Commanders  need  information  and  knowledge  to  make  effective  decisions  in  all  elements  of 
combat  or  crisis  operations.  As  the  speed  of  operations  accelerates,  commanders  require  more 
responsive  processes  for  decision-making.  Because  of  their  traditional  use  of  ISR  to  gather 
information  of  strategic  value,  control  of  those  assets  has  been  retained  at  the  very  high  levels 
and  priority  given  to  collection  for  Washington  decision  makers.  There  is  a  growing  recognition 
that  those  assets  need  to  support  the  Joint  Task  Force  (JTF)  Commander.  Significant 
improvements  have  been  implemented  and  others  planned  to  make  these  systems  more 
responsive  to  the  dynamics  of  combat  and  crisis  operations.  U.S.  Space  Command  has 
implemented  a  number  of  support  concepts  to  aid  the  supported  CINC  and  the  JTF  Commander. 
Other  assets,  such  as  the  Joint  Surveillance  Target  Attack  Radar  System  and  the  Predator  and 
Global  Hawk  unmanned  aerial  vehicles,  have  been  designed  to  give  the  operational  commander 
dedicated  assets  to  support  operations. 

Integration  of  this  capability  is  essential  to  optimize  the  commander’s  knowledge  of  the 
battlespace.  Sensor  management  is  an  integral  part  of  C  .  The  only  way  to  speed  the  planning 
and  execution  process  is  to  dynamically  manage  the  ISR  assets.  Combining  ISR  and  combat 
aircraft  to  find  and  destroy  moving  or  movable  targets  requires  the  dynamic  execution  of  both 
capabilities.  Therefore  the  study  concluded  that  ISR  is  an  essential  element  of  C2. 
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1.6  Combat  Information  Management 

Dynamic  battle  management  requires  the  management  of  infonnation.  Joint  Vision  2010  defines 
the  goal  of  information  dominance.  But  infonnation  dominance  implies  more  than  just  obtaining 
information:  it  means  converting  that  information  to  a  complete  understanding  of  the  situation 
and  sharing  that  understanding  with  decision  makers  at  every  echelon  at  the  right  time,  in  the 
right  format,  and  at  the  right  level  of  detail.  The  amount  of  information  available  to  commanders 
today  has  increased  dramatically  in  both  quantity  and  quality.  But  possession  of  large  amounts 
of  information  does  not  necessarily  enhance  C2.  Information  overload;  lack  of  interoperability; 
immaturity  in  fusion;  outdated  tactics,  techniques,  and  procedures  (TTPs);  and  the  lack  of  an 
information  operations  function  all  contribute  to  latency  in  decision  making. 

This  Study  recognizes  the  need  to  enhance  C  by  creating  an  information  management  capability, 
including  trained  staff;  TTPs;  and  support  tools  to  control  access  and  ensure  dissemination  to 
authorized  users.  The  SAB  studies  on  C2  in  1996  and  on  infonnation  management  in  1998  and 
1999  are  recommended  for  further  understanding  of  this  issue. 

1.7  Summary 

The  chapter  provides  the  foundation  and  context  for  the  remainder  of  the  report.  The  Air  Force’s 
documented  difficulty  in  achieving  the  needed  capability  of  C2  as  well  as  the  value  of  C2  in 
today’s  and  future  operations  should  stimulate  the  reader  to  understand  the  study’s  conclusions 
and  recommendations.  The  importance  of  ISR  and  combat  information  management  is  also 
included. 

What  follows  are  the  reports  of  the  individual  panels  making  up  the  study  team.  The  reports  are 
organized  with  the  panel’s  detailed  findings  and  recommendations  included  in  those  chapters. 
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Chapter  2 

Concept  and  System  Definition  Panel 


2.1  Introduction 

2 

The  1996  Air  Force  Scientific  Advisory  Board  (SAB)  Command  and  Control  (C  )  study  stated, 
“Systems  are  stovepiped  from  the  very  beginning  in  terms  of  how  they  are  defined,  funded, 
advocated  and  managed  by  the  Air  Force. .  .The  stove  piping  problem  extends  to  the  very  core  of 
how  forces  are  equipped.”  An  additional  theme  is  reflected  in  Einstein’s  words:  “The  world  we 
created  today  has  problems  which  cannot  be  solved  by  thinking  the  way  we  thought  when  we 
created  them.”  Achieving  the  Air  Force  Chief  of  Staffs  (CSAF’s)  goal  of  linking  together  Air 
Force  C  requires  that  we  not  only,  look  back  at  what  the  Air  Force  has  already  tried  in  the  past, 
but  also  follow  Einstein’s  advice  and  fundamentally  change  the  way  the  Air  Force  thinks  about 
C2. 

2.2  History  “Lessons  Observed” 

CSAFs  have  chartered  numerous  studies  and  conducted  many  four  star  reviews  in  their  attempts 
to  “fix”  the  Air  Force  C  problem.  These  CSAF  studies  began  with  the  1986  Air  Force  Studies 
Board  Summer  Study,  this  study  was,  in  turn,  followed  by  1992  and  1993  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  Broad  Area  Reviews,  1996  SAB  Summer 
Study,  1997  C2  Task  Force,  1997  C2  Four-Star  Summit,  and  this  2000  SAB  C2  Summer  Study. 
The  CSAFs  also  established  a  new  Air  Staff  C2  Directorate,  an  Air  Staff  C2  General  Officer 
Steering  Group,  and  the  Aerospace  C  Intelligence,  Surveillance  and  Reconnaissance  (ISR) 
Center  in  their  attempts  to  “fix”  C2. 

The  redirection  of  this  year’s  SAB  Summer  Study  from  “limited  forward  basing”  to  “C  ”  reflects 
the  CSAF’s  continuing  frustration  with  Air  Force  C2  capability.  Each  of  the  past  studies  made 
recommendations  for  fixing  the  problems  the  Air  Force  was  having  with  C  .  Analysis  of  study 
recommendations  indicates  that  the  same  recommendations  were  made  many  times,  yet  the 
service  is  not  achieving  the  vision  of  Air  Force  command  centers  that  are  linked  together  and 
have  the  capability  to  collaborate  globally  in  support  of  all  commanders  in  chiefs  (CINCs), 
services,  allies  and  the  Aerospace  Expeditionary  Force  (AEF). 

2.3  Commitments  and  Culture 

A  thorough  review  indicates  that  the  recommendations  of  this  study  are  consistent  with  those  of 
past  studies  on  Air  Force  C2.  For  10  years  the  Air  Force  has  accurately  and  repeatedly  identified 
its  C2  problems,  worked  the  margins,  and  not  made  substantial  progress  in  resolving  these 
persistent  problems.  The  Air  Force’s  fragmented  and  stovepiped  major  air  command 
(MAJCOM)  views  of  C  are  the  result  of  a  weak  Air  Force  commitment  to  the  importance  of 
enterprise-wide  Air  Force  C2  capability.  In  addition,  the  Air  Force  system  of  education,  training 
and  operations  does  not  inculcate  current  and  future  leaders  with  an  abiding  awareness  that  C  is 
the  foundation  upon  which  all  the  Air  Force  core  competencies  are  built.  Consequently,  Air 
Force  management  of  its  C"  enterprise,  throughout  its  history,  has  lacked  vision  and  a  constancy 
of  purpose.  All  the  good  intentions  and  actionable  recommendations  of  today  will  be  stacked 
with  those  of  yesteryear’s  studies  unless  senior  leadership  demands  an  enterprise-wide  view  of 
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C~  and  is  committed  to  building  the  capability.  The  leadership  must  also  ensure  that  this 
enterprise-wide  C2  capability  is  trained  and  operated  in  peacetime,  as  it  will  operate  in  wartime. 
Air  Force  MAJCOMs  do  not  go  to  war  individually,  but  team  together  in  support  of  all  CINCs, 
services,  allies  and  the  AEF.  Therefore  an  enterprise-wide  C  system  is  needed. 

2.4  Establishing  and  Managing  the  Air  Force  C2  Enterprise 
2.4.1  Institutionalizing  Enterprise-Wide  C2 

A  clear  vision  must  guide  any  organizational  transfonnation  by  motivating  and  compelling  its 
people.  A  C2  vision  should  be  short  and  simple,  capturing  C2  as  the  core  business  of  the  Air 
Force.  It  should  re-enforce  the  doctrinal  value  of  centralized  planning  and  decentralized 
execution,  provide  a  theater  perspective,  and  clarify  the  command  relationships  to  achieve  unity 
of  command.  Such  a  vision  of  Air  Force  C  exists.  It  was  documented  in  the  Aerospace 
Command  and  Control,  Intelligence,  Surveillance,  and  Reconnaissance  Center’s  (AC2ISRC’s) 
USAF  C2  CONOPS,  Dynamic  Aerospace  Command — USAF  Command  Centers  Collaborating 
Globally  in  Support  of  all  CINCs,  sendees,  allies  and  the  AEF.  It  should  be  embraced  by  the  Air 
Force  leadership  and  institutionalized.  Such  a  vision,  backed  by  senior  leadership’s  commitment 
to  transformation,  will  enable  the  Air  Force  to  embrace  a  true  understanding  of  C2  as  the  life¬ 
blood  to  Global  Vigilance,  Global  Reach,  and  Global  Power.  The  Air  Force  also  needs  to  follow 
the  Joint  Staff  s  Joint  Vision  2010  (. JV2010 )  lead  and  elevate  C2  to  a  prominent  role  in  its  vision. 

Recommendations 

•  Endorse  and  institutionalize  a  compelling  C2  vision — the  first  step  to  recognizing  the  essential 
link  between  aerospace  power  and  C2.  (CSAF) 

•  Add  an  enterprise-wide  vision  of  C2  to  the  Air  Force  Vision  Statement  to  ensure  that  C2  becomes 
the  foundation  for  Air  Force  core  competencies  (CSAF) 

•  Ensure  that  this  Air  Force  C2  vision  supports  the  JV2010  and  FV2020  visions 
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2.4.2  C2,  The  Foundation  of  the  Global  Engagement  Arch 
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Effectively  accomplishing  the  Air  Force  mission  depends  on  how  C"  is  performed.  As  a  result, 
C“  should  be  viewed,  along  with  quality  people,  as  the  foundation  of  the  Global  Engagement 
Arch.  It  is  the  enabler  for  the  effective  employment  of  Aerospace  Power.  The  Key  to  achieving 
an  elevated  role  for  C  and  the  vision  of  “command  centers  collaborating  globally”  is  to  establish 
an  empowered  single  manager  for  C2  at  Air  Force  level. 

Recommendations 

Establish  a  single  manager  for  C2  at  Air  Force  level.  (CSAF) 

Individual  should 

•  Be  an  Air  Force  Council  member 

•  Have  C2  operational  experience 

•  Be  empowered  to  propose  solutions  to  cross-program  and  MAJCOM  issues 

•  Be  the  Air  Force  Chief  Information  Officer  (CIO)  and  represent  the  Air  Force  at  the  Department 
of  Defense  (DoD)  CIO  Panel 

•  Have  assigned  directors,  to  include  C2,  Communications,  ISR,  and  Agile  Combat  Support  and 
have  appropriate  liaisons/DRUs 

•  Hire  skilled  Information  Technology  experts  and  C2  professionals  for  key  positions.  IP  As  should 
be  considered  for  these  positions. 

•  Be  responsible  for  publishing  a  single  Air  Force  C2ISR  Strategic  Plan  that  provides 
comprehensive  Air  Force  direction  for  C2  operations,  modernization  and  sustainment 

•  Define  and  sponsor  a  unifying  infrastructure  approach  to  system  development 
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2.4.3  The  Air  Force  C2  System  and  Enterprise- wide  C2  Management 

The  lack  of  understanding  of  the  Air  Force  C  vision  and  constancy  of  purpose  is  evident  at 
many  levels.  Examples  are:  the  excessive  number  of  Program  Element  (PE)  Codes  spread 
across  too  many  panels  in  the  Air  Force  Corporate  Process;  too  many  offices  in  charge  of 
different  parts  of  the  same  C  system,  no  central  Global  Command  and  Control  System  (GCCS) 
management  structure  aligned  with  Joint  Staff  instructions;  confusing  placement  of  AC2ISRC 
under  a  MAJCOM  while  it  holds  Air  Force-level  responsibilities,  and  so  on.  This  lack  of 
coherent,  focused  management  at  the  Air  Force  leadership  level  has  fostered  stove  piped  C2 
systems,  multiple  disparate  improvement  efforts  striving  for  similar  outcomes,  confused  training 
requirements,  inadequate  manning,  and  difficulty  in  deciding  on  a  baseline  C2  structure. 

The  Air  Force  also  needs  to  view  its  C"  system  as  an  integrated  system  of  weapon  systems  that  is 
composed  of  many  C2  centers  or  nodes.  Each  is  managed  as  a  “weapon  system”  and  has  a 
Designed  Operational  Capability  Statement,  operational  qualifications,  currency  requirements, 
and  inspection  programs.  In  addition,  the  Air  Force  should  manage  these  C2  weapon  systems 
with  the  same  job  performance  and  safety  standards  as  it  does  other  weapon  systems  that  have 
life-and-death  operational  consequences.  The  goal  of  a  C 2  improvement  program  should  be  a 
distributed  and  collaborative  system  of  systems  operated  by  certified  C2  warriors.  Additionally, 
an  effective  C2  capability  requires  an  effective  Common  Operational  Picture  (COP)  that  not  only 
correlates  data,  but  also  fuses  information  into  knowledge  for  the  decision  maker.  The  COP’s 
role  in  Air  Force  C2  is  crucial  because  it  will  dictate  the  nature  of  information  management  at  all 
theater  levels,  from  the  weapons  system  displays  to  the  theater  CINC  or  Joint  Task  Force 
Commander’s  operational  picture. 

The  following  recommendations  are  the  result  of  applying  an  Air  Force  enterprise-wide  view  of 
C"  to  the  Air  Force  Planning,  Programming,  and  Budgeting  System;  the  Requirements  System, 
the  Acquisition  System  and  C4I  Support  plans.  There  are  six  fundamental  components  of  the 
enterprise-wide  C  weapons  system:  (1)  individual  command  centers  and  nodes,  (2)  C  I  software 
applications,  (3)  C4I  software  infrastructure,  (4)  communications  infrastructure  (5)  the 
information  infrastructure  and  (6)  Air  Force  sensor  programs. 

Following  is  a  detailed  description  of  the  six  major  components  of  the  C  weapons  system: 

1.  Individual  C~  Command  Centers  and  Nodes :  The  foundation  of  this  Air  Force  enterprise¬ 
wide  view  is  C2  centers  and  nodes  that  are  managed  as  an  integrated  weapons  system 
consisting  of  people,  processes,  and  technology.  These  C2  Centers  are  operated  by  many 
MAJCOMs  and  must  be  manned  by  highly  trained  and  certified  C2  warriors.  The  C2  warriors 
are  not  only  highly  skilled,  for  example,  in  the  combat,  mobility,  space,  and  special 

operations  missions  but  also  in  the  art  and  science  of  the  application  of  aerospace  power  in 
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joint  and  combined  operations.  Fundamental  to  the  success  of  the  proposed  Air  Force  C 
weapon  system  concept  is  an  enterprise-wide  vision  of  a  globally  collaborating  partnership  of 
Air  Force  C  centers  and  nodes.  These  C  centers  and  nodes  bring  to  the  CINCs  a  multi- 
MAJCOM  C2  capability  that  is  far  greater  than  the  sum  of  its  parts.  Each  weapon  system 
node  is  funded  by  a  program  element  that  funds  manpower,  communications  and  computer 
equipment,  facilities,  and  sustainment.  All  program  elements  should  be  assigned  to  a  single 
C4I  panel  in  the  Air  Force  Corporate  Process.  Each  node  has  a  concept  of  operations 
(CONOPS)  and  a  set  of  training  publications — such  as  Air  Force  Instructions  (AFIs)  and 
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tactics,  training,  and  procedures  (TTPs) — that  describes  its  responsibilities  within  the 
enterprise-wide  C2  system  and  how  it  functions  in  the  multi-Service  and  joint  enterprise-wide 
C2  system.  Each  node  should  also  have  a  C4I  Support  Plan  that  describes  its  configuration 
control  process  and  how  it  will  be  sustained.  Finally,  weapon  system  nodes  should  have  a 
supporting  System  Program  Office  and  an  Acquisition  Program  Management  Decision.  The 
CONOPS,  Operational  Requirements  Documents  (ORDs),  PEs,  Program  Management 
Directives  (PMDs),  Program  Managers  (PMs),  C4I  Support  Plans  (C4ISPs)  and  Mission  Area 
Plans  (MAPs)  need  to  be  redrafted  and/or  reorganized  so  that  they  all  align  by  weapon 
system  node.  For  example  the  air  operations  center  (AOC)  (and  all  other  nodes  in  the  system 
of  weapon  systems)  needs  it’s  own  CONOPS,  ORD,  PE,  PMD,  PM,  C4ISP,  etc.  Aligning 
these  documents  and  entities  by  node  is  key  to  achieving  the  Air  Force  C2  vision  of 
“command  centers  collaborating  globally.”  The  system  of  weapon  systems  should  be 
described  and  defined  in  one  overarching  CONOPS,  one  Strategic  Plan,  one  Capstone 
Requirements  document,  etc.  A  single  integrating  PMD  should  also  be  written  to  direct  the 
various  MAJCOMs  and  agencies  to  take  the  actions  necessary  to  achieve  the  Air  Force  C2 
vision.  Well-defined  actions  should  be  spelled  out  in  this  integrating  PMD.  See 
Appendix  2D  for  a  matrix  table  depicting  the  above  concept. 

2.  C4 1  Applications:  C4I  applications  are  the  software  information-processing  and  decision 
tools  of  the  C2  Weapons  System.  Not  every  C2  center  may  use  the  same  C4I  applications. 
Some  applications  will  be  common  across  all  C2  centers;  however,  other  applications  will 
provide  specialized  capability.  For  example,  Air  Mobility  Command  (AMC)  or  Space 
Command  may  use  applications  that  Combat  Air  Forces  do  not  use,  such  as  AMC’s  C2 
Information  Processing  System  or  Space  Command’s  Space  Battle  Management  System. 

3.  Software  Infrastructure:  The  software  infrastructure  should  be  the  common  software 
foundation  that  supports  all  C2  weapons  systems  nodes.  It  is  common  across  all  MAJCOMs, 
CINCs,  and  Services.  All  C4I  applications  and  software  infrastructure  development  efforts 
should  be  consolidated  under  two  programs:  the  Global  Command  and  Control  System- Air 
Force  (GCCS-AF)  and  GCCS-AF  Real  Time  Weapons  Control.  The  requirements  for  these 
two  programs  should  be  identified  in  a  single  ORD  for  each  program  and  each  program  must 
have  a  single  PE,  PMD,  MAP,  and  C4ISP.  Both  programs  should  be  consolidated  on  a  single 
C4I  panel  within  the  Air  Force  corporate  process.  Information  systems  that  support  agile 
combat  support  tracking  and  decision-making  should  be  developed  under  the  GCCS-AF 
program. 

4.  Communications  Infrastructure:  The  supporting  communications  infrastructure  is  divided 
into  four  areas:  (1)  tactical  communications,  (2)  base-level  communications,  (3)  long-haul 
communications,  and  (4)  satellite  communications.  Requirements  for  the  communications 
infrastructure  should  be  identified  in  a  single  ORD,  and  funding  provided  in  a  single  PE  for 
each  of  the  four  areas.  All  four  programs  should  be  consolidated  on  a  single  C4I  panel  within 
the  Air  Force  corporate  process  and  have  a  single  MAP  and  C4ISP. 

5.  Information  Infrastructure:  The  information  infrastructure  consists  of  three  parts: 

(1)  common  infonnation  management,  (2)  datalinks,  and  (3)  Joint  Interoperability  Tactical 
Command  and  Control  Systems  message  sets.  All  three  areas  should  be  consolidated  under  a 
single  GCCS-AF  Integration  Program  and  have  a  single  CONOPS,  ORD,  PMD,  MAP,  and 
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C4ISP.  All  three  programs  should  be  consolidated  under  a  single  C4I  panel  in  the  Air  Force’s 
Corporate  Process. 

6.  Air  Force  Sensor  Programs :  The  platforms  associated  with  these  programs  are  outside  the 
C2  Weapons  System;  however,  they  are  the  eyes  and  ears  of  C4I,  and  the  infonnation  they 
provide  is  a  fundamental  part  of  the  C  weapons  system. 

The  above  proposal  would  greatly  simplify  what  are  now  complex  and  fragmented  C  programs 
into  fewer  logical  and  well-defined  and  -understood  components  of  the  C2  weapons  system. 

Recommendations 

Formalize  the  definition  of  the  C2  system  of  C2  weapon  systems  and  nodes 

•  Develop  and  align  an  overarching  family  of  C2  CONOPS  (AF/XO) 

•  Develop  and  align  (flSPs  to  the  C2  Weapon  Systems  and  nodes  (AF/SC) 

•  Develop  a  capstone  PMD  with  subordinate  PMDs  and  System  Program  Offices  that  are  aligned 
with  the  family  of  C~  CONOPS  (AF/XO) 

•  Merge  the  C&I  Support  Plan  and  the  C2ISR  Campaign  Plan  into  a  single  Air  Force  C2  Strategic 
Plan  (Air  Force  CIO) 

•  Restructure  programs  and  PEs  bv  using  the  C2  System  of  Weapons  System  and  nodes  and  links 
concept  (AF/XP) 

•  Designate  the  individual  C2  centers  and  nodes  as  weapon  systems  and  inspect,  train,  and  operate 
them  as  such  (AF/XO) 
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Create  and  fund  a  C~  integration  program 

•  Establish  a  C 2  Integration  Program  Office  that  is  empowered  to  direct  and  coordinate  all 
interoperability  development  between  C2  centers  and  nodes  (SAF/AQ  and  AF/XO) 

•  Create  and  maintain  a  capabilities-based  C2  Weapons  System  Roadmap  and  review  it  regularly 
(AF/XO) 

•  Create  and  maintain  a  cross-program  C2  Weapon  Systems  Integration  Roadmap  to  monitor 
progress  and  for  review  by  the  CSAF  and  the  Secretary  of  the  Air  Force  (SAF)  annually  at  the  C2 
capabilities-based  Quarterly  Acquisition  Program  Review  (SAF/AQ  and  AF/XO) 

•  Develop  a  long-term  strategy >  for  cultivating  the  Joint  Battlespace  InfoSphere  ( JB1 )  and  fund  it 
(AF/XP  and  AF/XO) 

•  Establish  the  Integration  Task  Force  as  per  AFI 63-123  (AF/XO) 

2.5  Expeditionary  Air  Force  C2  Baseline 

The  Expeditionary  Air  Force  C"  system  of  systems  is  a  subset  of  the  Air  Force  C  enterprise¬ 
wide  C2  system  and  is  composed  of  the  continental  United  States  (CONUS)  based  command  and 

9 

intelligence  centers  and  of  the  Theater  Air  Control  System  with  its  supporting  airlift  C 
capability.  The  various  nodes  are  operated  by  numerous  MAJCOMs  and  agencies.  Therefore, 
overall  management  and  integration  of  this  system  of  systems  that  will  “collaborate  globally  in 
support  of  the  CINCs”  must  be  accomplished  at  the  Secretariat  and  Air  Staff  levels  of  the  Air 
Force. 
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2.5.1  Expeditionary  Aerospace  C2  System  Components 

2 

This  section  describes  the  existing  C  centers  (see  Figure  2-2)  that  support  a  commander’s 
capability  to  plan,  direct,  coordinate,  and  control  forces  to  accomplish  assigned  missions. 


Figure  2-2.  Expeditionary  Aerospace  C2  System  Centers 


2.5.2  The  Theater  Air  Control  System 

Air  Force  forces  (AFFOR)  respond  to  worldwide  missions  in  support  of  theater  CINC  missions 
that  require  deployment  of  Air  Force  C  capability.  At  the  operational  level  of  warfare,  C 
weapons  systems  provide  Air  Force  C2  in  support  of  the  Aerospace  Expeditionary  Task  Force 
Commander,  Commander,  Air  Force  Forces  (COMAFFOR),  and  the  Joint/Combined  Force  Air 
Component  Commander  (J/CFACC). 

Air  Force  Forces  Headquarters  (HQ):  The  mission  of  the  AFFOR  FIQ  is  to  plan,  monitor, 
execute,  and  assess  Air  Force  operations  and  sustainment  in  support  of  COMAFFOR.  It  is 
functionally  separate  from  the  AOC’s  air  operations  planning  and  execution  activities;  however, 
AFFOR  activities  fundamentally  affect  the  air  campaign  by  both  enabling  and  constraining  air 
operations.  The  AFFOR  HQ  is  COMAFFOR’s  C2  element.  COMAFFOR  C2  has  two  facets: 
operational  and  service.  The  operational  commander  handles  technical,  administrative,  and 
tactical  matters.  The  service  element  manages  the  “beds,  beans,  and  bullets”  issues. 

Combined  Aerospace  Operations  Center  (CAOC):  The  overarching  mission  of  the  CAOC  is 
to  employ  decisive  joint  and  coalition  aerospace  power  through  effective  C  in  support  of  aligned 
commands  and  CINCs  worldwide.  The  CAOC  is  the  operational  C2  center  in  which  the  CFACC 
has  centralized  the  functions  of  planning,  direction,  and  control  over  aerospace  resources.  The 
CAOC  performs  duties  in  support  of  the  C/JFACC,  the  Airspace  Control  Authority  and  the  Area 
Air  Defense  Commander.  The  CAOC  produces,  distributes,  and  executes  the  integrated  air 
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tasking  order  (ATO).  Individuals  representing  joint,  coalition  and/or  allied  forces  assist  in  the 
operation  of  the  CAOC. 

Control  and  Reporting  Center  (CRC):  The  CRC  is  directly  subordinate  to  the  CAOC  and  is  a 
primary  control  node  concerned  with  decentralized  execution  of  air  operations.  The  CRC  directs 
region  or  sector  air  defense  and  provides  aircraft  control  and  monitoring  for  both  offensive  and 
defensive  missions.  The  CRC  also  may  establish  liaison  with  allies  or  components  to  exchange 
airspace  management  and  air  defense  data  from  related  control  systems. 

Control  and  Reporting  Element  (CRE):  The  CRE  is  subordinate  to  the  CRC  and  augments 
the  CRC’s  mission  by  extending  radar  surveillance  and  airspace  control  capabilities  within  the 
area  of  responsibility. 

Air  Support  Operations  Center  (ASOC):  The  ASOC  is  directly  subordinate  to  the  AOC  and 
is  the  primary  liaison  element  to  the  corps  headquarters  for  air  support.  It  is  primarily  concerned 
with  the  exchange  of  combat  information  between  air  and  ground  units  for  immediate  air  support 
of  ground  operations.  It  plans,  coordinates,  and  directs  tactical  air  support  of  ground  forces, 
normally  at  corps  level  or  below.  The  ASOC  is  delegated  execution  authority  to  provide  fast 
reaction  to  requests  for  offensive  air  support  such  as  close  air  support  (CAS)  or  air  interdiction. 

Tactical  Air  Control  Party  (TACP):  The  TACP  is  subordinate  to  ASOC  and  responsible  for 
controlling  close  air  support  and  advising  and  assisting  the  U.S.  Army  commander  when  air 
support  is  required. 

Wing  Operations  Center  (WOC):  The  WOC,  both  fixed  and  deployed,  includes  the  following 
functional  areas:  operations  control,  maintenance  coordination,  reports,  training,  and  battle 
management  and  survival  recovery.  MAJCOMs,  in  coordination  with  assigned  or  supported 
CINCs,  may  specify  additional  functions  for  collocation  or  removal  from  the  WOC. 

Tanker  Airlift  Control  Element  (TALCE):  The  TALCE  coordinates  and  executes  both 
preplanned  and  immediate  airlift  requirements  with  Tanker  Airlift  Control  Center  (TACC)  and 
the  Air  Mobility  Division  (AMD)  within  the  AOC.  The  TALCE  reports  to  the  Air  Mobility 
Element  within  the  AMD  of  the  CAOC.  TALCE  cadre  members  are  responsible  for  conducting 
airfield  assessments  worldwide.  TALCEs  are  provisional,  deployed  organizations  composed  of 
various  mission  support  elements,  established  at  fixed,  deployed,  and  en  route  locations  where 
operational  support  is  non-existent  or  insufficient. 

2.5.3  Theater  Airborne  C2  Assets 

Airborne  Warning  and  Control  System  (AWACS):  AWACS  performs  missions  designed  to 
extend  radar  coverage,  enhance  link  operations,  assist  in  track  identification,  and  gather 
intelligence  data.  AWACS  provides  all-weather,  all-terrain  target  detection,  weapons  control, 
and  threat  warning.  AWACS  provides  area  surveillance  and  control  when  ground  radars  are  not 
in  place,  augments  operational  radars,  supports  air  operations  conducted  in  support  of  ground 
forces,  and  provides  surveillance,  early  warning  of  hostile  aircraft,  control  of  fighter  aircraft, 
airspace  management,  and  ADA  coordination  functions  during  contingency  operations. 

Airborne  Battlefield  Command  and  Control  Center  (ABCCC):  The  ABCCC  operates  as  part 
of  the  Airborne  Elements  of  the  Theater  Air  Control  System.  Its  primary  function  is  to  provide 
management  of  tactical  air  forces  and  to  liaison  with  ground  forces.  Its  general  employment  role 
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is  an  extension  of  AOC  combat  operations  and  as  an  alternate  ASOC/Direct  Air  Support  Center. 
However,  an  integrated  battle  management  and  communications  system  onboard  the  EC-130E 
aircraft  enables  the  battle  staff  to  provide  air  and  ground  component  commanders  with  a  flexible 
airborne  C  capability. 

Joint  Surveillance  Target  Attack  Radar  System  (JointSTARS):  JointSTARS  provides 
dedicated  support  to  ground  commanders  for  planning  and  execution  of  the  land  battle  and 
theater  air  interdiction  campaign.  JointSTARS  is  a  theater-wide  battle  management  C  platform 
that  conducts  ground  surveillance  to  develop  an  understanding  of  the  enemy  situation. 
JointSTARS  also  provides  attack  support  functions  to  friendly  offensive  air  elements. 

A-10  Forward  Area  Controller  (FAC-A):  TACP  operating  from  a  suitable  aircraft,  the  FAC-A 
coordinates  air  strikes  between  the  TACP  and  CAS  aircraft.  The  FAC-A  provides  tenninal 
control,  relays  CAS  reports,  provides  immediate  target  and  threat  reconnaissance,  and  marks 
targets  for  the  attacking  aircraft.  The  FAC-A  can  perform  tactical  battle  management  by  cycling 
the  CAS  flights  through  the  target  area,  while  prioritizing  the  targets  in  coordination  with  the 
friendly  ground  force. 

2.5.4  Supporting  CONUS  Command  Centers 

The  following  Air  Force  Commander  in  Chief,  U.S.  Space  Command  (USCINCSPACE)  and 
U.S.  Transportation  Command  centers  provide  critical  support  for  successful  Expeditionary 
Aerospace  Force’s  (EAF’s)  operations  in  support  of  the  CINC. 

Air  Force  Space  Command  (AFSPACE)  AOC:  The  AFSPACE  AOC  facilitates  the 
integration  of  information  and  resources,  implements  and  coordinates  the  Commander, 
AFSPACE  (COMAFSPACE)  tasking  and  priorities,  makes  recommendations  to  superiors,  and 
validates  and  prioritizes  requests  for  USCINCSPACE.  The  14AF  AFSPACE  AOC  is  an  in-place 
equivalent  of  the  theater  AOC  and  accomplishes  parallel  planning  and  operational  functions  for 
COMAFSPACE 

Tanker  Airlift  Control  Center  (TACC):  The  TACC,  Headquarters  AMC,  located  at  Scott  Air 
Force  Base  (AFB),  IF,  is  the  command’s  hub  for  planning,  scheduling,  tasking,  and  executing 
America’s  mobility  forces  around  the  world.  The  TACC  is  dedicated  to  providing  quality 
service  to  a  wide  range  of  mobility  customers.  In  effect,  the  TACC  is  “one-stop  shopping,” 
which  brings  requirements  and  capabilities  together  to  accomplish  AMC’s  Global  Reach  mission 
efficiently  and  effectively. 

Air  Force  Information  Warfare  Center  (IWC):  The  Air  Force  Infonnation  Warfare  Center  at 
Kelly  AFB,  TX,  engages  in  a  myriad  of  activities  supporting  its  role  as  the  Air  Force  Information 
Warfare  executive  agent.  Its  mission  is  to  develop,  maintain,  and  deploy  information  warfare 
and  C"  warfare  capabilities  in  support  of  operations,  campaign  planning,  acquisition,  and  testing. 

2.5.5  Operational  and  Systems  Architecture  Development  Factors 

Each  of  the  above  centers  is  responsible  for  a  variety  of  C  functions  which  are  supported  by  a 
“business  process”  that  is  defined  in  an  operational  architecture  and  infonnation  technology 
systems  and  by  communications  that  are  defined  by  a  systems  architecture.  This  section  offers 
an  analysis  of  operational  and  systems  architecture  development  factors. 
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The  C  system  is  a  system  of  systems  (as  shown  in  Figure  2-3).  The  large  majority  of  individual 
elements  that  make  up  the  overall  C2  system  are  contributed  by  non-  C2  organizations.  In  fact, 
the  unique  functions  of  the  C2  system  are  planning  and  execution  control. 

Elements  of  each  C“  System  are  unique  to  the  theater  or  crisis.  These  include  the  specific 
allocated  ISR  assets,  weapon  delivery  platforms,  communications,  combat  support,  and 
information  management  systems. 

Additional  assets  may  be  available  on  a  shared  basis  to  the  commander  and  augment  the  organic 
systems — specifically,  strategic  ISR  and  infonnation  management  systems,  long-range  weapon 
delivery  platforms  such  as  B-2s,  long-haul  communications,  and  logistics  and  combat  support 
systems. 

The  interactions  between  these  systems  in  a  C"  context  are  dominated  by  information  exchanges, 
principally  in  the  fonn  of  tasking,  collected  sensor  data,  and  system  status  and  capability 
reporting. 


The  nature  of  systems  of  systems  is  that  the  user  does  not  have  the  option  to  specify  the  nature  of 
the  interfaces  between  the  component  systems.  It  is  thus  incumbent  on  the  system  architects  and 
acquisition  organizations  to  assure  that,  to  the  extent  possible,  operational  systems  conform  to 
interface  standards  that  enable  the  user  to  configure  a  system  of  systems  that  meets  the  needs  of 
the  particular  situation.  The  set  of  interfaces  that  are  appropriate  include  those  implemented  by 
the  systems  of  the  other  Services  and  U.S.  allies. 
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Figure  2-3.  Existing  C2  System  Architecture 


The  component  functions  that  make  up  the  Planning  and  Execution  Control  Process  (see 
Figure  2-4)  include  assessment,  strategy  decision,  planning  and  resource  allocation,  and  dynamic 
execution.  Assessment  includes  the  analysis  of  ISR  data  and  the  characterization  of  the  current 
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situation.  Strategy  decisions  set  the  objectives  of  the  campaign  and  describe  the  desired  effects 
to  be  achieved  by  aerospace  power.  The  planning  process  leads  to  allocation  of  available 
resources  as  reflected  in  taskings  levied  on  organic  weapon  systems,  ISR  assets,  communications 
resources,  and  combat  support  organizations.  Some  taskings  are  requests  for  resources  held  at  a 
higher  level  that  may  or  may  not  be  granted.  To  the  extent  that  these  requests  for  shared 
resources  are  not  satisfied,  the  associated  plans  will  have  to  be  adjusted  or  alternative  courses  of 
action  initiated  to  accommodate  the  deficiency. 

Once  the  plan  begins  execution,  adaptation  and  adjustment  will  be  necessary  to  fix  evolving 
problems  and  maintain  the  initiative. 


Figure  2-4.  Planning  and  Execution  Management 


The  planning  and  resource  allocation  process  in  an  AOC  is  responsive  to  the  individual  mission 
areas  and  functions  that  staff  the  AOC.  These  include  air  interdiction,  airlift,  close  air  support, 
combat  search  and  rescue,  communications,  defensive  counter-air,  information  operations, 
intelligence  analysis,  ISR  collection  management,  logistics,  offensive  counter-air,  special 
operations  strike,  suppression  of  enemy  air  defenses,  and  tanker  support. 

The  above  sections  of  this  report  started  with  a  concept  of  an  Air  Force  enterprise- wide  view  of 
C2  that  could  be  used  to  pull  together  and  link  C2  within  the  Air  Force.  We  also  added  more 
“meat  on  the  bones”  on  managing  C  as  a  weapons  system  and  proposed  a  concept  for  the 
Expeditionary  Aerospace  C2  System.  The  Expeditionary  Aerospace  C2  System  comprises 
globally  linked  command  centers  and  nodes  with  C  -assigned  forces  and  is  trained  and  equipped 
to  collaborate  in  support  of  the  theater  CINCs  and  Joint  Force  Commanders  (JFCs).  This  next 
section  focuses  on  the  theater  subset  of  the  Expeditionary  Aerospace  C  System. 
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2.6  Building  the  Future — The  Theater  Aerospace  Command  and  Control  System 
(TACCS) 

2.6.1  Combined  Aerospace  Operations  Center 

The  possibility  that  an  Air  Force-provided  AOC  will  operate  in  war  as  a  “U.S.-only”  command 
center  is  highly  remote.  Theater  air  operations  will  be  combined  operations.  As  a  result,  the 
design  of  the  AOC  weapons  system  must  deal  with  the  security  issues  associated  with 
multinational  air  operations.  The  SAB  believes  that  these  requirements  not  adequately  addressed 
in  the  AOC  Weapons  System  requirements  and  are  not  adequately  addressed  in  its  system 
architecture  design. 

This  section  presents  significant  issues  that  will  affect  a  commander’s  ability  to  plan  and  execute 
an  air  campaign.  The  SAB  proposes  the  following  approaches  to  improve  Air  Force  CAOC 
organization,  training,  and  equipage. 

2.6.2  CAOC/AOC  Organization 

The  organization  of  the  Theater  Air  Control  System  is  well  defined  and  documented,  with  the 
exception  of  the  CAOC/AOC.  Air  Force  AOCs  support  a  wide  variety  of  CINCs  throughout  the 
world.  The  fact  that  these  Air  Force  AOCs  support  a  wide  variety  of  commands  often  results  in 
extensive  customization.  Other  Air  Force  weapon  systems  are  not  customized  for  each  theater  of 
operations.  CAOC/AOC  should  follow  the  “organize,  train,  and  equip”  concept  the  Air  Force 
uses  for  other  major  weapon  systems,  such  as  the  F-15,  F-16,  and  AWACS.  These  are  not 
customized  by  theater,  but  provided  by  the  Service  to  the  theater  as  a  combat  capability  package. 

The  CAOC  is  the  operational  C  center  in  which  the  CFACC  has  centralized  the  functions  of 
planning,  directing,  and  controlling  aerospace  resources.  The  probability  that  the  Air  Force  will 
operate  a  “U.S.  only”  AOC  is  extremely  remote,  yet  many  of  our  development  efforts  do  not 
address  the  underlying  coalition  security  and  system  engineering  issues  in  the  technical  design  of 
the  AOC  systems  infrastructure.  Coalition  operations  must  be  viewed  as  the  operational  baseline 
of  the  CAOC/AOC  Weapon  System  and,  as  a  result,  become  the  driving  force  behind  its 
organization,  technical  design,  and  systems  engineering.  The  following  is  a  description  of  its 
basic  organizational  structure. 

CAOC  Divisions:  The  CAOC/AOC  has  five  core  divisions. 

Strategy  Division:  The  Strategy  Division  develops,  refines,  disseminates,  and  assesses  the 
progress  of  the  JF ACC’s  aerospace  campaign  strategy. 

Combat  Plans  Division:  The  Combat  Plans  Division  is  responsible  for  Joint  Aerospace 
Operations  Center  (JAOC)  near-term  aerospace  operations  planning.  It  refines,  disseminates, 
and  assesses  the  progress  of  the  JFACC  aerospace  strategy.  It  also  prepares  and  refines  two 
ATOs  beyond  the  executing  ATO. 

Combat  Operations  Division:  The  Combat  Operations  Division  executes  the  ATO.  It 
analyzes,  prioritizes,  and,  if  necessary,  recommends  redirection  of  assets  to  the  JFACC.  It  also 
coordinates  emergency  air  support  requests. 
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Intelligence,  Surveillance,  and  Reconnaissance  Division:  The  ISR  Division  provides 
integrated  distribution  of  ISR  information  and  processes.  It  also  develops,  plans,  and  coordinates 
all  aspects  of  ISR  capabilities  for  the  planning,  execution,  and  assessment  responsibilities  of  the 


CAOC/AOC. 


Air  Mobility  Division:  The  Air  Mobility  Division  plans,  coordinates,  tasks,  and  executes 
intratheater  and  intertheater  air  mobility  forces.  It  coordinates  aerial  refueling  plans,  tasks,  and 
schedules.  The  Air  Mobility  Division  ensures  that  air  mobility  missions  are  visible  in  the  AMC 
standard  C2  system  and  reflected  in  the  ATO/Airspace  Control  Order. 
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Figure  2-5.  CAOC/AOC  C2  System  Operational  Relationship 


CAOC/AOC  Combat  Operations  Staff:  An  AOC  is  led  by  an  AOC  Director,  has  five 
divisions,  and  multiple  support  teams.  As  an  example,  the  following  are  brief  descriptions  of 
principal  positions  in  a  combat  operations  division. 

CAOC/AOC  Director:  The  AOC  Director  is  responsible  for  the  centralized  planning,  directing, 
controlling,  and  coordination  of  air  effort  and  all  JFACC  assets.  Responsibilities  of  the  Director 
include  supervising  the  five  AOC  divisions  and  approving,  as  well  as  releasing  for  publication, 
the  ATO.  The  AOC  Director  also  monitors,  evaluates,  and  adjusts  as  necessary  to  meet  changing 
tactical  situations  while  executing  the  ATO.  The  AOC  Director  advises  the  commander  of 
problems  or  factors  affecting  achievement  of  assigned  objectives. 
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Director  of  Combat  Operations  (DCO):  The  DCO  works  for  the  AOC  Director  and  is  in 
charge  of  24-hour  operations  in  the  Combat  Operations  Division  (COD).  The  COD  is 
responsible  for  the  current  ATO  during  execution  and  for  making  necessary  changes  to  affect  the 
theater  air  operations. 

Chief,  Combat  Operations  (CCO):  The  CCO  reports  directly  to  the  DCO  and  has  overall 
responsibility  for  the  direction  and  supervision  of  the  COD.  The  CCO  ensures  that  current 
operations  correspond  to  JFC/JFACC/AFFOR  directives  and  is  responsible  for  maintaining 
viable  air  and  missile  warning  as  well  as  defense  operations.  At  the  discretion  of  the  AOC 
Director,  the  CCO  may  be  the  senior  officer  within  the  COD. 

Senior  Offensive  Duty  Officer  (SODO):  The  SODO’s  main  role  is  to  monitor  ATO  execution 
and  make  recommendations  to  the  CCO.  The  SODO  exercises  authority  over  offensive  and 
support  operations.  The  SODO  supervises  the  individual  mission  cells  and  weapon  system 
experts  who  augment  those  positions.  The  SODO’s  main  role  is  to  monitor  ATO  execution, 
recommend  changes  to  the  ATO,  and  manage  mission  and  strike  package  retasking  as  directed 
by  the  CCO. 

Fighter  Duty  Officer:  The  job  of  Combat  Operations  duty  officers  is  to  be  the  expert  in  their 
assigned  aircraft  and/or  mission  specialties.  They  represent  the  concerns  of  their  deployed  and 
employed  units  and  act  as  a  conduit  for  information  between  their  units  and  the  AOC  leadership. 

The  SAB  suggests  reorganizing  the  CAOC  using  the  joint  staff  structure.  This  results  in  a  widely 
understood  CAOC  organization  that  is  fully  compatible  with  all  other  Services’  and  CINCs’ 
organizational  structures. 
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Figure  2-6.  Proposed  AOC  Joint  Organizational  Structures 


Recommendations 

Build  CAOCs — not  AOCs.  Deal  with  the  security  and  weapons  system  design  challenges  up 
front  (AF/XO) 

Reorganize  the  CAOC  using  the  joint  organizational  model  (AF/XO) 
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2.6.3  AOC  Process  Issues 


While  the  fundamental  mission  of  every  CAOC/AOC  is  similar,  each  theater  perfonns  CAOC 
functions  differently.  Historically,  there  has  been  little  effort  to  standardize  CAOC  operations. 
The  North  Atlantic  Treaty  Organization  Allied  Tactical  Air  Forces  (ATAFs)  each  planned  and 
executed  their  air  campaigns  using  different  procedures  and  equipment.  For  example,  CONUS 
augmentees  to  the  2ATAF  CAOC  in  northern  Germany,  known  as  the  Allied  Tactical  Operations 
Center,  would  find  very  different  procedures  and  processes  from  those  found  in  the  CAOCs 
supporting  4ATAF  (southern  Germany),  7AF  (Korea)  and  the  CONUS-based  numbered  air 
forces  (8AF,  9AF,  and  12AF). 

It  seems  clear  that  the  Air  Force  needs  to  implement  a  CAOC  “baseline”  that  provides  a 
significant  level  of  standardization  while  providing  some  flexibility  for  unique  theater 
operational  needs.  Standardized  CAOC  processes  would  allow  a  far  more  efficient  cross-flow  of 
trained  people,  provide  rapid  absorption  of  augmentation  personnel,  and  set  the  framework  for 
other  management  actions  to  further  improve  the  overall  conduct  of  Air  Force  C2.  A 
standardized  CAOC  would  also  improve  the  worldwide  applicability  of  the  CAOC  training 
provided  by  the  C2  Training  and  Innovation  Group  (C2TIG)  at  Hurlburt  Field. 

The  C2TIG  has  led  the  development  of  a  detailed  hierarchy  of  publications  for  use  by  fielded 
CAOCs  and  training  organizations.  However,  the  majority  of  these  documents  remain  in  draft 
form. 


Table  2-1.  AOC  Related  Publications 


Title 

Date 

Status 

Air  Force  C2  CONOPS 

24  Mar  1999 

Signed 

Enroute  Operations  Center  (EOC)  CONOPS 

30  Jun  2000 

Draft 

Space  Operations  Center  CONOPS 

15  Marl  999 

Signed 

C2  ISR  CONOPS 

24  Jul  2000 

Draft 

Battle  Control  System  CONOPS 

4  Nov  1999 

Draft 

Time-Critical  Targeting  (TCT)  CONOPS 

8  July  1997 

Signed 

Air  Force  AOC  CONOPS 

19  Apr  2000 

Draft 

AFI  13-1  Vol.  1  (AOC  Training) 

16  Jan  1997 

Draft 

AFI  13-1  Vol.  Ill  (AOC  Operations  Procedures) 

6  Mar  2000 

Draft 

EAF  C2  Reference  Book 

27  Jan  2000 

Approved  for  use 

AOC  Process  Manual 

1  July  2000 

Draft 

Blue  Order  of  Battle  CONOPS 

12  Aug  2000 

Draft 

2 

The  SAB  supports  the  work  being  done  by  the  C“TIG  at  Hurlburt  Field.  A  multi-command  AOC 
baseline  group  exists,  draft  AOC  baseline  publications  have  been  written  and  it  appears  that  the 
Air  Force  is  moving  toward  a  standardized  CAOC/AOC  organization.  These  efforts  have  also 
been  sensitive  to  retaining  limited  flexibility  for  theater-specific  uniqueness.  In  addition,  the 
AC2ISRC  and  the  C2TIG  have  produced  significant  numbers  of  CONOPS,  AFIs,  and  TTP 
manuals.  It  was  the  opinion  of  the  SAB  that  sufficient  CONOPS  exist  to  guide  development  of 
the  CAOC;  however,  more  work  is  needed  in  many  areas  on  training  publications.  While  the 
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CAOC/AOC  baseline  project  is  not  a  full  solution  for  CAOC  standardization,  it  does  set  the 
stage  for  the  follow-on,  detailed  work  required  to  standardize  all  Air  Force  CAOCs. 

2.6.4  Improve  Theater  C2  Training 

The  Air  Force  proudly  points  to  its  core  competencies  because  of  their  uniqueness  to  the  Air 
Force  and  the  superior  way  in  which  they  are  accomplished.  Highly  effective  training  is  the 
main  reason  for  the  Air  Force’s  superior  execution  of  its  core  competencies.  Such  is  not  the  case 
with  Air  Force  theater  C2  operations  from  the  unit  level  to  the  JFACC.  The  Air  Force  does  not 
provide  the  same  quality  of  training  for  theater  C  as  for  its  core  competencies.  Improving  the 
quality  of  theater  C2  training  will  provide  an  exponential  improvement  in  aerospace  operations 
efficiency  and  capability. 

Growing  C  warriors  and  leaders  who  understand  the  art  and  science  of  the  application  of 
aerospace  power  is  the  foundation  for  eliminating  the  pick-up  team  process  now  used  to  support 
a  wartime  contingency.  Realistic  daily  C  training,  high-quality  people,  and  connected  C 
systems  will  significantly  improve  theater  C2  capabilities. 

Achieving  this  objective  will  require  theater  C  training  that  is  integrated  with  the  peacetime 
flying  training  and  is  done  routinely  during  the  5 -day  workweek.  Integrating  AOC  training  with 
other  theater  control  centers  and  real-world  flying  training  will  improve  the  quality  of  theater  C2 
training  and  standardization.  Today’s  theater  C  system  also  needs  to  have  an  effective 
certification  process  for  AOC  operators  and  inspections  to  ensure  compliance  with  AFIs. 
Establishing  realistic  and  regular  training,  standardization  and  inspection  will  greatly  improve 
the  Expeditionary  Air  Force’s  ability  to  make  a  smooth  transition  from  peacetime  to  wartime 
operations. 

Recommendations 

Establish  a  career  track  for  C2  warriors  (AF/XO  and  AF/DP) 

Improve  JFACC  and  CAOC  training  from  the  Numbered  Air  Force  down  to  the  wings  and  air 
control  centers  (AF/XO  and  AF/DP) 

Improve  cross-MAJCOM  C2  training  for  support  of  the  EAF  (AF/XO  and  AF/DP 
Improve  Joint  and  coalition  C2  training  (AF/XO  and  AF/DP) 

2.6.5  CAOC/AOC  Training  Issues 

Air  Force  CAOC/AOC  training  programs  have  lagged  in  definition  and  rigor  when  compared  to 
other  weapons  systems.  This  results  in  a  pick-up  team  approach  for  CAOC  operations  in  both 
exercises  and  in  real-world  contingencies — a  major  operational  problem. 

A  brief  review  of  the  history  of  formal  CAOC/AOC  training  may  help  frame  the  overall  issue  as 
it  exists  today.  The  Air  Force  created  the  Blue  Flag  program  in  the  late  1970s  with  the  objective 
of  providing  AOC  training.  The  initial  goal  was  to  train  potential  AOC  augmentees  in  theater- 
specific  processes  and  procedures.  Typically,  Blue  Flag  would  plan  an  exercise  such  as  Korea  by 
visiting  the  theater  well  in  advance  of  the  exercise  date.  The  visit  focused  on  identifying  current 
theater  procedures,  updating  the  Blue  Flag  library  with  the  theater  documents,  and  identifying 
selected  theater  personnel  to  come  to  the  exercise  and  act  as  advisors.  The  Blue  Flag  AOC  was 
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configured  to  replicate  the  theater-specific  facility.  This  approach  provided  a  reasonably  high 
degree  of  fidelity  with  regard  to  each  theater’s  AOC  processes.  In  the  late  1980s,  both  9AF  and 
12AF  began  using  Blue  Flag  as  a  training  vehicle  and  helped  develop  the  warfighting  scenarios. 
The  numbered  air  force  (NAF)  staffs  relocated  to  Hurlburt  once  a  year  for  Blue  Flag  training 
which  was  focused  and  received  very  high  marks  from  Gen  Horner  after  his  Desert  Stonn 
experience. 

While  Blue  Flag  continues  to  provide  valuable  training,  there  is  no  effective  mechanism  to 
identify,  train  and  track  people  who  have  been  trained  in  theater-specific  processes  and 
procedures  for  CAOC  operations. 

A  second  issue  is  the  manner  in  which  CAOC/AOC  training  is  conducted.  The  requirements  for 
AOC  training  are  defined  in  AFI  13-1,  Vol.  3.  This  document  provides  a  well-recognized 
training  construct  of  initial  qualification  training,  mission  qualification  training  (MQT),  and 
continuation  training  (CT);  however,  continuity  of  this  construct  falls  apart  during 
implementation.  The  MQT  program  is  implemented  as  a  local  unit-training  program  and  may 
not  provide  the  trainee  a  realistic  picture  of  the  dynamic  CAOC  environment.  CT  is  also 
conducted  at  the  unit  level  with  occasional  opportunities  to  work  in  a  CAOC  exercise,  such  as  a 
Blue  Flag,  Ulchi  Focus  Lens,  or  similar  Joint-level  exercises.  The  SAB  concluded  that  current 
training  falls  far  short  of  what  is  needed  and  that  training  is  not  consistent  with  the  Air  Force’s 
belief  that  we  must  “train  the  way  we  fight.”  The  CAOC  Weapons  System  is  complex  and  needs 
to  be  “flown”  regularly — not  once  or  twice  a  year.  Theater  Battle  Management  Core  System 
(TBMCS),  the  primary  software  system  for  the  CAOC,  is  extremely  capable,  but  complex.  No 
one  individual  understands  its  full  capability.  Just  as  Air  Force  operators  must  fly  complex 
aircraft  frequently  and  regularly  to  maintain  proficiency,  C2  warriors  must  operate  the  complex 
CAOC  weapon  system  frequently  and  regularly  to  maintain  proficiency. 

Recommendations 

Initiate  an  effective  and  reliable  system  to  track  CAOC-trained personnel  (AF/DP) 

Identify  specific  CAOC-trained  personnel  to  fill  in  as  augmentees  for  unmanned  CAOC  “spaces” 
during  contingencies  (AF/XO) 

Task  frequent  12/5  CAOC  operations  for  Continuation  Training  (AF/XO) 

Evaluate  the  effectiveness,  style,  and  size  of  CAOC  training  programs-explore  distance  learning 
(AF/XO) 

Manage  the  CAOC  as  a  Weapon  System  (AF/XO) 

•  Train  CAOC  personnel  “ the  way  we  fight ” 

•  Develop  a  Designed  Operational  Capability  Statement 

•  Establish  standards  of  performance  and  an  effective  training,  standardization  evaluation, 
and  inspection  program 

•  Conduct  joint  training — both  live  and  virtual 

•  Conduct  Operational  Readiness  Inspections 
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2.6.6  CAOC/AOC  Manning  Issues 

Air  Force-provided  AOCs  are  not  fully  manned,  and  there  is  no  reason  to  expect  this  situation  to 
improve.  The  problem  is  further  exacerbated  by  the  lack  of  C  Warrior  School  slots  and  the 
limited  number  of  Blue  Flag  training  opportunities.  This  lack  of  quality  training  opportunities 
keeps  AOC  operational  proficiency  low.  The  Air  Force  also  has  not  operationally  tested  and 
validated  its  AOC  Unit  Manning  Documents. 

The  number  of  people  required  for  the  AOC  Quick  Response  Package  (QRP),  Limited  Response 
Package  (LRP),  and  Theater  Response  Package  (TRP)  has  never  been  operationally  tested  and 
verified.  However,  the  Air  Force  has  recently  proposed  a  new  Unit  Type  Code  (UTC) 
composition  for  the  QRP,  but  the  package  has  not,  at  this  time,  been  operationally  tested  and 
verified.  Table  2-2  analyzes  potential  AOC  manning  reductions  based  on  the  fielding  of 
operationally  significant  new  technology  (TBMCS)  and  implementation  of  an  effective  AOC 
training  program. 


Table  2-2.  Potential  Reductions  in  AOC  Manning 
AOC/AFFOR 


Sorties/day 

Size 

Today 

2001 

2005 

300-900 

QRP 

441 

350 

250 

900-1,800 

LRP 

870 

600 

400-500 

1,800-3,000 

TRP 

1,055/146 

800/99 

600-700/80 

(Note:  QRP  and  LRP  do  not  include  AFOR  manning) 


The  SAB  also  believes  that  the  number  of  Air  Force  AOCs  must  be  reduced  in  order  to  fix  the 
AOC  manning  and  training  problem.  Today  AOC-assigned  manpower  is  about  30  percent  less 
than  authorized,  a  situation  that  is  not  expected  to  improve  in  the  near  tenn.  Furthermore,  there 
are  not  enough  school  slots  available  at  the  Hurlburt  C  Warrior  School  to  sustain  the  AOC  crew 
force,  and  Blue  Flag  training  opportunities  for  the  AOC  Weapon  System  are  limited.  The 
current  manning  situation,  together  with  the  lack  of  quality  training  opportunities,  severely 
impacts  AOC  operational  readiness.  Therefore,  to  improve  AOC  readiness,  the  board 
recommends  a  reduction  in  the  total  number  of  Air  Force  AOCs  to  five  and  the  realignment  of 
existing  manpower  as  shown  in  Table  2-3.  This  reduction  in  AOCs  will  allow  the  remaining 
AOCs  to  be  fully  manned  and  fix  the  30  percent  less  than  authorized  situation  of  the  NAFs 
today.  The  Combat  Air  Forces  NAFs,  without  AOCs,  could  become  Regional  Engagement 
Headquarters. 
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Table  2-3.  CAOC/AOC  Manning  Proposal 


Numbered 
Air  Force 

NAF/AFFOR 

Manning 

AOC 

Peacetime 

Manning 

AOC 

Wartime 

Manning 

ARF  UTC 
Manning 

Active  UTC 
Manning 

Area  of  Operations 

7AF 

99 

QRP/350 

TRP/800 

250 

200 

U.S.  Forces  Korea 

8AF 

99 

QRP/350 

LRP/600 

125 

125 

Pacific  Command 

9AF 

99 

LRP/600 

TRP/800 

200 

Central  Command 

12AF 

99 

LRP/600 

TRP/800 

200 

Southern  Command, 
European  Command 
(EUCOM)-Africa 

16AF 

99 

QRP/350 

LRP/600 

125 

125 

EUCOM 

Regional 

Engagement 

NAF 

3AF 

99 

5AF 

99 

1 1 AF 

99 

13AF 

99 

Total 

891 

2250 

3600 

900 

450 

The  above  number  of  AOCs  is  notional;  however,  three  fundamental  AOC  requirements  must  be 
met  when  determining  the  number  of  AOCs  that  the  Air  Force  can  support:  (1)  The  Air  Force 
should  ensure  that  all  AOC  Weapon  System  authorized  manpower  positions  are  filled  and  that 
this  staff  is  fully  trained  in  peacetime.  They  will  provide  a  highly  effective  initial  AOC  combat 
capability  until  the  augmentation  forces  arrive.  (2)  The  Air  Force  Reserve  and  Guard  should 
provide  at  least  one-third  of  the  wartime  augmentees.  They  have  provided  high-quality,  trained 
forces  for  theater  AOCs.  (3)  If  additional  augmentees  are  required,  they  should  be  sourced  from 
one  of  the  other  four  fully  trained  AOC  staffs.  Following  the  above  recommendations  will  fix 
most  of  our  current  AOC  pick-up  team  deficiencies.  SAB  also  believes  that  8AF  should  be 
authorized  a  QRP  so  that  they  can  train  with  an  AOC  staff  and  not  become  another  “behind  the 
Green  Door”  information  operations  organization.  This  would  also  allow  8AF  to  use 
collaborative  tools  to  support  other  NAFs’  peacetime  training  requirements. 

Recommendations 

Operationally  test  and  validate  the  AOC  UTCs  based  on  a  fully  trained  AOC  staff  and 
operationally  effective  technology  (TBMCS) 

Reduce  the  number  of  Air  Force-provided  AOCs  to  five  and  fully  man  this  C~  Weapon  System 
(CSAF) 

2.6.7  Time-Critical  Targeting  (TCT) 

TCT  will  require  a  change  in  how  the  Air  Force  thinks  about  C  .  It  will  impact  theater  C 
architecture  design,  modernization,  and  training.  Although  the  TCT  target  set  may  be  small  or 
non-existent  during  the  initial  phase  of  an  air  campaign  and  overall  is  a  fraction  of  total  C2 

2 

activity,  TCT  needs  will  push  operational  process  improvement,  pull  technologies,  and  drive  C 
efficiency.  An  effective  TCT  capability  will  require  superior  coordination  and  C2  of  sensors 
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operating  in  air,  ground,  and  space  and  simple  intuitive  tools  for  C  warriors  to  effectively  find, 
fix,  target,  track,  engage,  and  assess  any  target  in  the  BattleSpace.  Building  an  effective  TCT 
capability  can  be  the  operational  imperative  that  breaks  down  the  organizational,  technology,  and 
process  stovepipes  that  constrain  C2  effectiveness  today.  Aircraft  weapon  systems  and  munitions 
are  designed  and  built  to  meet  the  most  demanding  missions.  TCT,  the  military’s  most 
demanding  C  mission,  can  and  should  be  the  driving  force  behind  Air  Force  theater  C  and  ISR 
modernization  and  development.  Developing  a  highly  effective  TCT  capability  will  address 
most  theater  C  mission  deficiencies  that  exist  today.  These  capabilities  include  automated: 
intelligence  preparation  of  the  battlefield  (IPB)  development,  effects-based  targeting,  and  effects- 
based  combat  assessment.  Other  enhancements  required  include  quality  COP,  enhanced 
information  operations/ISR  control  cell,  integrated  database,  Web-enabled  and  enhanced 
communications. 

If  C"  warriors  are  able  to  successfully  direct  TCT  engagements,  C  in  other  theater  mission  areas 
will  also  significantly  improve.  The  AC2ISRC’s  TCT  analysis  in  its  Family  of  Systems 
Requirements  Document,  1 1  January  2000,  and  Strategy  and  Modernization  Plan  for  Time 
Critical  Targeting  and  Real  Time  Information  to  the  Cockpit,  7  February  2000  (approved  by  the 
Air  Force  Requirements  Oversight  Council)  is  extensive  and  addresses  the  key  end-to-end 

organization,  process,  and  technology  issues  for  fixing  TCT.  This  analysis  offers  the  Air  Force  a 

2 

“silver  thread”  that  can  be  used  as  the  foundation  for  the  joint  and  multi-Service  theater  C 
system  modernization. 

Recommendations 

Accelerate  the  multi-service  and  joint  staffing  of  the  Defeating  Theater  Time  Critical  Targets 
requirements  document  (AF/XO) 

Develop  and  fund  a  TCT  science  and  technology  research  and  development  program  (SAF/AQ 
and  AF/XP) 

Fund  and  implement  an  effective  TCT  spiral  development  program  (SAF/AQ,  AF/XP,  and 
AF/XO) 

Fund  and  quickly  transition  operationally  significant  TCT  technologies  and  TTPs  to  the  field 
(SAF/AQ,  AF/XO,  and  AF/XP) 

2.6.8  Develop  and  Field  the  Battle  Control  Center  (BCC) 

The  BCC  concept  will  provide  a  modernized  decentralized  C  execution  node  for  the  Air 
Component  Commander  and  CAOC.  It  should  be  organized  to  direct  air  battle  execution, 
theater  air  defense,  data  link  management,  combat  identification,  and  surveillance.  The  BCC 
should  provide  the  Air  Component  Commander  and  JFC  with  a  near-real  time  means  of 
managing  a  single  integrated  air  picture  from  air-,  sea-,  land-,  and  space-based  sensors.  Not  only 
should  the  BCC  provide  the  Air  Component  Commander  with  the  personnel,  TTPs,  and 
equipment  necessary  to  direct  and  control  theater  air  operations,  but  the  BCC  should  be  equipped 
and  trained  to  conduct  limited  theater  planning,  coordinate  air  operations  with  other  joint  and 
combined  forces,  and  directly  augment  the  Air  Component  Commander’s  airspace  control  and 
area  air  defense  commander  functions.  When  equipped  and  trained  as  described,  the  BCC  can 
serve  as  a  backup  to  the  CAOC. 
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Recommendations 

Accelerate  modernization  of  the  TACCS  to  ensure  development  and  fielding  of  the  BCC  (initial 
operating  capability  [IOC]  not  later  than  2005)  (AF/XP,  AF/XO,  and  SAF/AQ) 

Manage  the  BCC  as  a  weapon  system  (AF/XO) 

2.6.9  Ensure  Joint  Interoperability 

No  single  Service  has  the  C  ,  sensors,  and  weapons  systems  to  accomplish  all  DoD  missions. 
Therefore,  each  Service  must  be  able  to  leverage  another  Service’s  situational  awareness  and 
weapons  systems  capabilities.  Dynamic  re  tasking  of  aircraft  in  support  of  commanders’ 
priorities  will  require  rapid  access  to  appropriate  databases  to  obtain  the  near-real  time 
information  that  is  essential  for  dynamic  decision  making.  Joint  interoperability  also  requires 
Air  Force  C2  systems  that  are  interoperable  with  GCCS  and  other  service  C2  systems. 
Interoperable  databases  and  appropriate  data  links  are  the  foundation  of  this  capability.  The 
following  initiatives  are  needed  for  the  joint  interoperability  of  the  future  TACCS: 

1.  Develop  and  refine  the  Joint  COP:  Air  Force  and  Army  information  systems  cannot  now 
rapidly  exchange  data  in  support  of  dynamic  retasking.  There  is  a  need  to  resolve 
interoperability  issues  between  TBMCS  and  the  Army  Battle  Control  System  (ABCS). 
Furthermore,  there  is  a  need  to  develop  joint  TTPs  that  outline  how  all  service  sensors 
support  the  near-real  time  COP  and  targeting. 

2.  Develop  procedures  for  cross-cueing  of  Service  ISR  assets:  ISR  assets  currently  work  as 
stove  piped  systems,  but  target  attack  often  requires  cross-cueing  of  other  ISR  assets  to  verify 
and/or  refine  information.  New  procedures  are  needed  to  cross-cue  sensors  and,  if  required, 
provide  continuous  target  coverage  until  the  mission  is  completed.  For  example,  the  AOC 
should  have  data  links  to  the  Corps’  Deep  Operations  Coordination  Cell  (DOCC)  to 
nominate  targets  for  Army  ISR  asset  coverage.  Likewise,  the  DOCC  should  be  able  to 
nominate  targets  for  Air  Force  ISR  asset  coverage. 

3.  Refine  ATO  procedures:  While  the  Air  Force,  Navy,  and  Marine  Corps  all  control  aircraft 
by  tail  number,  the  Army  controls  helicopters  by  units  as  a  subset  of  the  combined  arms  team 
near  the  forward  line  of  troops  (FLOT)  or  when  attacking  targets  beyond  the  FLOT.  The  72- 
hour  ATO  process  appears  to  be  too  restrictive  to  accommodate  helicopter  missions  that  are 
responding  to  the  ground  commander  taskings.  However,  helicopters  need  to  be  included  in 
the  ATO  process  to  prevent  fratricide  and  coordinate  Suppression  of  Enemy  Air  Defenses 
(SEAD)  and  Combat  Search  and  Rescue  (CSAR).  Interoperable  information  systems  should 
pennit  the  addition  of  helicopters  to  the  ATO  on  relatively  short  notice.  For  example,  the 
DOCC  could  provide  placeholders  30-plus  hours  in  advance  and  wait  until  the  last  possible 
time  (for  example,  6  hours)  to  provide  specifics.  We  recommend  that  procedures  be 
developed  between  TBMCS  and  the  Advanced  Field  Artillery  Tactical  Data  System 
(AFATDS)  to  accomplish  the  short-notice  inclusion  of  helicopters  in  the  ATO. 

4.  Complete  the  development  of  TBMCS — AFATDS  interoperability:  AFATDS-TBMCS 
interoperability  is  essential  for  integrating  battle  plans  and  coordinating  situational 
awareness.  The  effective  exchange  of  information  between  the  AOC  and  DOCC  will  rapidly 
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improve  joint  target-weapon  pairing  capability.  The  DOCC  can  also  quickly  receive  the 
ATO  and  ATO  updates  from  the  AOC  and  pass  Candidate  Targeting  Lists  to  the  AOC. 

5.  Ensure  TBMCS  can  access  the  Army’s  All  Source  Analysis  System  (ASAS)  data:  ASAS 
can  contribute  to  the  air  COP  by  providing  information  for  IPB,  situational  awareness,  and 
near-real  time  retasking  of  strike  aircraft.  Interoperability  gateways  will  permit  passing  of 
tactical  electronic  intelligence  reports  and  other  tactical  reports,  as  well  as  interactive 
TBMCS-ASAS  databases. 

6.  Improve  air-ground  operations  situational  awareness:  CAS  must  have  situational 
awareness  on  the  location  of  friendly  ground  forces  to  prevent  fratricide  and  improve  support 
to  the  ground  force  commander.  The  Anny  and  Air  Force  should  establish  a  gateway 
between  the  Army’s  Enhanced  Position  Location  Reporting  System  Enhanced  Position 
Location  Reporting  System  (EPLRSj/Virtual  Message  Fonnat  (VMF)  ground  network  and 
the  Joint  Data  Network  so  that  CAS  aircraft  have  accurate  locations  of  friendly  ground 
forces.  The  Army  should  also  be  encouraged  to  modify  its  VMF  message  formats  to  include 
altitude  and  height  information.  This  would  result  in  a  more  accurate  location  of  ground 
forces  for  CAS  aircraft. 

7.  Refine  joint  airspace  clearance  procedures:  There  appears  to  be  a  need  to  clarify  the 
Army  Tactical  Missile  System  (ATACMS)  immediate  and  preplanned  fires  procedures 
within  Joint  Doctrine. 

8.  Improve  mission  planning,  rehearsals,  and  retasking:  JFCs  lack  the  ability  to  conduct 
real-time  mission  planning  before  redirection  of  strike  aircraft.  The  Rome  Laboratory’s 
Information  for  Global  Reach  program  may  allow  ground  commanders  to  conduct 
collaborative  planning  with  air  commanders  while  missions  are  en  route  to  the  theater  of 
operations. 

9.  Place  more  emphasis  on  joint  training:  We  recommend  that  the  numbered  air  forces  and 
land  components  and  corps  participate  in  peacetime  ATO  development.  AOCs  should  also 
participate  in  Army  Corps  Warfighter  Exercises. 

Recommendations 

Refine  air-ground  operation  procedures  and  ensure  interoperability  of  C2  systems. 

•  Ensure  that  TBMCS  and  ABCS  are  interoperable  (AF/XO) 

•  Develop  operating  procedures  for  the  AOC  to  request  sensor  support  from  Army  ISR  assets  and 
for  the  DOCC  to  request  sensor  support  from  AOC  ISR  assets  (AF/XO) 

•  Refine  ATO  procedures  to  allow  reduced  timelines  for  inclusion  of  Anny  helicopters  in  the  ATO 
process  for  SEAD  and  CSAR  support.  Consider  using  AFATDS  connectivity  to  TBMCS  to 
expedite  the  process.  (AF/XO) 

•  Complete  the  development  of  gateways  between  TBMCS  and  AFATDS  (SAF/AQ) 

•  Establish  a  gateway  between  EPLRS/VMF  and  the  Joint  Data  Network  to  provide  CAS  aircraft 
with  accurate  locations  of friendly  ground  forces  (SAF/AQ) 

•  Refine  joint  airspace  clearance  procedures  to  include  ATACMS  immediate  and  preplanned  fires 
within  Joint  Doctrine.  Consider  the  TBMCS-AFATDS  and  the  TBMCS-Tactical  Airspace 
Integration  System  linkages  as  a  means  to  expedite  clearances.  (AF/XO) 
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•  Place  more  emphasis  on  joint  training  to  include  AOC  participation  in  all  Army  Corps 
Warfighter  Exercises  (AF/XO) 

Interoperability  issues  are  explored  in  detail  in  the  Report  of  the  Interoperability  Panel, 

Chapter  3. 

2.6.10  Air  Force  Forces 

Operations  from  World  War  II  to  the  present  continue  to  point  to  a  lack  of  progress  in  defining, 
organizing,  and  institutionalizing  a  theater-smart  highly  trained  AFFOR  capability.  More 
attention  is  needed  for  the  maturation  and  development  of  the  AFFOR  organizational  concept, 
staffing,  C2  training  and  exercises,  decision  support  systems,  processes,  and  UTCs. 

Senior  leadership  must  define  the  AFFOR  organization  and  develop  a  distributed  operations 
concept  using  forward  elements  and  reachback  locations.  The  AFFOR  staff  is  an  operational  Air 
Force  wartime  capability  and  must  be  established  and  ready  to  execute  its  mission  in  direct 
support  of  deployed  theater  aerospace  forces.  However,  the  Air  Force  has  often  used  existing 
resources  and  a  pick-up  team  when  an  operation  commences.  AFFOR  staff  must  be  assigned  to 
an  AFFOR  UTC  and  receive  effective  training  to  carry  out  their  mission.  Manning  for  AFFOR 
UTCs  should  be  sourced  from  previously  identified  and  trained  personnel  from  the  engaged  NAF 
staff,  non-engaged  NAF  staffs,  and  MAJCOM  staffs.  These  individuals  must  train  regularly  to 
perform  AFFOR  functions.  Commanders  may  tailor  and  position  AFFOR  C2  centers  to  support 
contingencies. 

AFFOR  functions  and  responsibilities  are  not  well  defined,  understood  or  implemented: 

The  corporate  Air  Force  needs  to  educate  ainnen  on  the  difference  between  the  Service  C2 
functions  of  the  AFFOR  staff  (HQ)  and  the  “operational”  C2  element,  the  J/CAOC. 

COMAFFOR  requires  a  capable  staff  to  plan,  deploy,  employ,  sustain,  and  redeploy  aerospace 
forces  to  carry  out  the  JFC’s  mission  objectives.  This  is  an  enduring  requirement  for  deployed 
aerospace  forces  and  is  separate  from  the  responsibilities  of  a  dual-hatted  COMAFFOR’s 
JFACC. 

AFFOR  functions  should  be  well  defined:  NAF  staffs  have  competing  missions  in  supporting 
both  their  J/CAOC  and  the  AFFOR  responsibilities.  The  current  Air  Force  structure  and 
CONOPS  assume  that  NAFs  provide  the  staff  for  an  AFFOR  forward  capability.  The  NAFs  are 
not  staffed  or  trained  to  carry  out  the  AFFOR  role. 

The  Air  Force  must  decide  how  to  transition  AFFOR  support  from  peacetime  to  wartime,  the 
organization  responsible  to  staff  the  AFFOR,  and  AFFOR  functions  that  can  be  deployed 
forward.  All  other  AFFOR  functions  should  be  performed  in  the  rear.  The  concept  for 
Operational  Support  Centers  (OSC)  is  sound  for  reachback  support. 

AFFOR  documentation  and  guidance  are  lacking:  An  agreed-upon  AFFOR  “roadmap”  does 
not  exist.  Over  the  past  2  years,  the  AC2ISRC  has  led  an  AFFOR  baseline  effort.  Many 
documents  were  written.  To  date,  the  UTCs  are  registered,  but  no  unit  is  responsible  for 
implementing  the  UTCs  and  Air  Force  approval  of  the  AFFOR  CONOPS,  operational  guidance, 
and  training  has  not  been  achieved. 

AFFOR  organizations,  systems,  processes,  and  allocation  of  manpower  must  be  defined  before 
training  programs  are  built.  The  AFFOR  baseline  team  started  from  scratch  and  developed  a 
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CONOPS  and  an  AFI  for  operational  guidance;  TTPs  are  in  development.  Once  staffed  and 
approved,  development  of  executable  AFFOR  UTCs  and  identification  of  AFFOR  training  needs 
will  follow. 

General  officer  ownership  and  guidance:  Air  Force  leadership  must  identify  an  advocate  to 
define  AFFOR  mission  requirements  and  capabilities.  Air  campaign  success  is  depends  on 
having  the  right  support,  at  the  right  time,  in  the  right  place.  The  AFFOR  provides  this  support. 
As  such,  AFFOR  is  a  capability  the  Air  Force  needs  to  support,  develop,  and  institutionalize. 

Recommendations 

Identify  an  Air  Staff  advocate  for  AFFOR  C2  requirements  and  capabilities  (CSAF) 

•  Define  and  fully  implement  the  AFFOR  organizational  concept  described  above  (CSAF) 

•  Identify >  and  train  AFFOR  staff  members;  NAFs,  MAJCOMs,  and/or  in-place  OSCs 
(AF/XO  and  AF/IL) 

•  Identify  AFFOR/AOC  functional  relationships  (AF/XO  and  AF/IL) 

•  Develop,  staff  and  approve  CONOPS,  AFI  (Vol.  1  and  III),  TTPs,  executable  UTCs,  and  logistics 
detail  (AF/XO  and  AF/IL) 

•  Determine  requirements  and  implement  regular  training  exercises  for  AFFOR  staffs 
(AF/XO  and  AF/IL) 

Further  define  the  forward/reachback  concept  for  AFFOR  operations  (AF/XO  and  AF/IL) 

2.7  GCCS-AF 

To  date,  the  Air  Force  has  produced  stove  piped  legacy  C  systems  across  numerous  mission 
areas  such  as  mobility,  space,  strategic,  ISR  planning  and  weapons  control,  mission  planning, 
theater  battle  management,  and  agile  combat  support.  Separate  acquisition  and  support  efforts 
have  led  to  duplicative  information  views  across  mission  areas  and  different  computing 
infrastructures.  These  stove-piped  C"  systems  have  limited  interoperability.  This  results  in 
multiple  C2  systems  within  C2  centers  that  provide  inconsistent  infonnation  views  and  produce 
complex  technology  environments  for  the  operator. 

Most  of  the  stove-piped  C  systems  can  be  attributed  to  multiple  C  management  structures, 
limited  cross-flow  of  requirements,  and  lack  of  a  consolidated  C2ISR  enterprise- wide  view  of  C2. 
These  separate  management  processes  have  resulted  in  stove-piped  system  production, 
duplication  across  mission  areas,  questionable  use  of  resources  (funding,  manpower),  and 
fragmented  information  to  the  warfighter.  The  separate  processes  that  manage  Air  Force  joint 
requirements  for  GCCS  and  TBMCS  are  an  example  of  multiple  C2  management  structures. 

2.7.1  Defining  GCCS-AF 

GCCS-AF  should  be  thought  of  as  the  Air  Force’s  implementation  of  the  Joint  GCCS  program, 
and  it  should  be  used  to  manage  and  define  the  automated  C2  and  ISR  mission  tools  for  Air  Force 
strategic,  theater,  wing,  and  unit  commanders. 

Merging  C  and  ISR  weapons  system  applications  into  a  single  GCCS-AF  C  system  will 
provide  the  warfighter  with  a  common  integrated  and  interoperable  family  of  C2  applications  that 
can  display  common  information  on  common  hardware.  GCCS-AF  should  be  linked  by  the 
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global  information  grid  and  enable  collaboration  with  all  warfighters,  including  the  CINCs  and 
other  Services. 


2.7.2  Implementing  GCCS-AF 

Movement  to  a  single  Air  Force  C  system  in  GCCS-AF  and  establishment  of  a  single  C 
management  oversight  structure  are  critical  to  the  Air  Force’s  C2  enterprise.  Several  systems 
must  be  folded  into  GCCS-AF  in  the  near  term  and  become  part  of  the  JBI  as  it  evolves. 
Figure  2-7  depicts  how  existing  systems  need  to  be  integrated  into  GCCS-AF. 


|  2000  |  2001  I  2002 

Baseline  >OC 

GCCS-AF  vl.O  GCCS-AF  v2.0 


I  2003  I  2004  |‘ 
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Vision:  Move  to  GCCS 


Figure  2-7.  GCCS-AF 


There  also  needs  to  be  an  Air  Force  policy  decision  that  directs  GCCS-AF.  The  integration  of  all 
future  Air  Force  unit-  and  force-level  applications  (for  example,  mission  planning,  crisis 
planning,  space  battle  management,  and  mobility  planning  and  execution  applications  on  the 
GCCS-AF  software  and  hardware  infrastructures)  should  be  clearly  stated  in  the  policy  directive. 
This  will  produce  an  integrated  C2  system  across  Air  Force  C2  domains  and  link  the  Air  Force  by 
2005. 

The  near-tenn  technical  strategy  for  an  integrated  GCCS-AF  should  include  migration  to  the 
joint  GCCS  common  integration  framework — the  Defense  Information  Infrastructure  Common 
Operating  Environment  (DII  COE)  Level  6.  This  should  continue  for  the  short  term;  however, 
the  mid-  to  long-term  solution  is  a  Web-based  integration  framework,  which,  in  turn,  will  enable 
the  development  of  a  full  JBI  capability.  This  concept  was  described  in  the  SAB’s  December 
1998  Study,  Information  Management  and  December  1999  Study,  Building  the  Joint  Battlespace 
InfoSphere. 

Recommendations 

Designate  GCCS-AF  as  the  Air  Force  C 2  system  (CSAF) 

•  Develop  and  expedite  transition  planning  to  consolidate  C2ISR  mission  functions  into  GCCS-AF 
(SAF/AQ) 

•  Establish  a  single  management  oversight  process  to  represent  the  Air  Force  in  joint  GCCS 
management  (AF/XO) 
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•  Establish  a  C2  integration  program  that  is  empowered  to  integrate  activities  between  the  various 
C2  centers  and  nodes  (SAF/AQ) 

2.8  Migrating  to  the  Joint  Battlespace  InfoSphere 

JBI  is  a  proposed  improvement  for  C"  that  recognizes  and  exploits  the  design  and  development 
processes  that  have  been  sweeping  across  the  commercial  information  technology  markets.  It 
represents  a  major  evolutionary  milestone  in  information  system  design  and  offers  operational, 
system,  and  technical  improvements.  Currently  there  is  no  Air  Force  program  that  provides  for 
developing,  acquiring,  or  fielding  the  JBI.  The  Air  Force  needs  to  establish  a  JBI  program,  and  it 
is  our  recommendation  that  it  be  an  infrastructure  element  of  the  GCCS-AF  and  Global  Combat 
Support  System- Air  Force  programs.  Resolving  the  technical  issues  involved  with  migrating 
from  today’s  GCCS  DII-COE  design  construct  to  the  JBI  design  construct  will  require  that  it  be 
closely  linked  to  the  GCCS  program.  Close  cooperation  with  Defense  Information  Systems 
Agency  (DISA)  and  DII  COE  governing  bodies  will  also  be  required. 

Figure  2-8  depicts  the  progression  in  software  design  styles.  Previously,  C  systems  were  built 
using  modular  software  in  which  the  system  comprised  software  code  that  was  easily 
distinguished  as  separate  software  modules.  Recently,  a  more  sophisticated  modular  software 
approach  has  been  used  in  which  the  applications  code  is  distinguished  from  the  infrastructure 
code.  This  infrastructure  code  provides  services  required  by  C2  applications  that  ride  on  the 
code;  the  infrastructure  code  is  built  using  common  commercial  sources.  The  DISA  DII  COE  is 
an  example  of  this  infrastructure  code  that  is  used  for  C2  systems  development  today. 
Interoperability  among  C  systems  was  thought  to  be  easier  if  systems  used  a  common 
infrastructure.  However,  it  is  becoming  widely  accepted  that  a  common  DII  COE  infrastructure 
is  insufficient  for  achieving  interoperability.  Common  data  semantics,  or  a  means  for  converting 
different  data  structures,  is  also  needed.  We  also  believe  that  the  burden  of  maintaining  common 
versions  of  DII  COE  across  different  C  and  ISR  systems  is  considerably  more  demanding  than 
maintaining  common  Web-based  protocols  for  information  exchange.  This  increasing  cost  for 
maintaining  the  DII  COE  will  motivate  the  development  of  the  JBI. 
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Figure  2-8.  Contrasting  Styles  of  Design 
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The  JBI  enables  interoperability  without  requiring  the  same  version  of  DII  COE  across  all  C 
systems.  As  a  result,  development  of  the  JBI  is  becoming  a  more  attractive  means  for  achieving 
interoperability.  The  prime  technical  mechanism  that  allows  systems  to  participate  in  the  JBI  is 
the  adoption  of  a  Web-enabled  information  exchange  process.  Today’s  web  technology  entails 
publishing  information  using  Extensible  Markup  Language  (XML)  and  using  subscriptions  or 
queries  to  retrieve  the  information.  Existing  systems  will  be  able  to  migrate  relatively  quickly  to 
the  JBI  by  adopting  the  XML  approach.  Future  systems  will  be  able  to  bypass  portions  of  the 
process  described  above  by  having  capability  modules  connect  directly  to  the  JBI.  As  more  and 
more  systems  adopt  the  Web-enabled  structure  as  an  internal  software  construct,  the  size  of  add¬ 
on  systems  will  diminish  because  the  JBI’s  individual  functionality  applications,  “fuselets,”  will 
offer  a  flexible,  easily  integrated,  and  easily  upgraded  and  maintained  capability  that  will  replace 
the  older  add-on  systems.  In  other  words,  application  modules  from  existing  systems  can  be 
migrated  over  time  from  residence  within  a  DII  COE  infrastructure  design  towards  residence 
within  an  InfoSphere  design.  The  exchange  of  information  among  modules  or  systems  will  be 
easier  to  manage  when  those  exchanges  are  accomplished  through  Web-enabled  interfaces, 
rather  than  through  adherence  to  common  (that  is,  the  same)  components. 

It  should  be  specifically  pointed  out  that  adherence  to  a  DII  COE  configuration  is  good  from  an 
integrated  product  standpoint.  For  example,  within  an  application,  the  use  of  standard  elements, 
standard  interfaces,  standard  protocols,  etc.,  is  good  practices  and  should  not  be  abandoned.  The 
SAB  suggests  that  it  is  not  necessary  for  all  C  systems  to  use  the  same  version  of  the  DII  COE 
and  is  not  recommending  abandonment  of  the  DII  COE  altogether.  Different  versions  are  OK 
when  using  the  JBI  strategy  to  satisfy  the  interoperability  objective.  However,  it  is  also 
important  to  adhere  to  good  software  engineering  practices  and  use  a  layered  architecture  and 
standard  components,  such  as  can  be  found  in  individual  versions  of  the  DII  COE,  to  develop 
individual  system  or  application  modules. 
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We  recommend  that  this  JBI  migration  be  funded  by  one  PE  and  be  managed  by  a  single  System 
Program  Office  (SPO)  that  is  devoted  to  fielding  Air  Force  enterprise-wide  interoperable  C2. 
Thus  it  makes  sense  to  consider  consolidating  existing  programs,  such  as  the  TBMCS,  along 
with  infrastructure  evolution  programs,  such  as  GCCS-AF,  into  a  single  office  that  is  devoted  to 
the  growth  and  fielding  of  the  JBI. 

Recommendations 

Develop  a  long-term  JBI  strategy  and  fund  it. 

•  Use  an  internet  or  Web-based  implementation  strategy >  (AF/XO  and  SAF/AQ) 

•  Use  the  Web  and  related  technologies  (such  as  XML)  emerging  from  the  commercial  world  for 
JBI  development  (SAF/AQ) 

•  Require  an  open  system  design  for  JBI  development  (SAF/AQ) 

2 

Establish  a  SPO  that  is  responsible  for  fielding  Air  Force  enterprise-wide  interoperable  C 
(SAF/AQ) 

2.9  Summary 

The  Air  Force  vision  of  “well-equipped  C"  centers  collaborating  globally  in  support  of  the 
CINCs”  can  be  rapidly  achieved  if  senior  Air  Force  leadership  strongly  endorses  the  need  for  an 
enterprise-wide  C  capability.  The  Air  Force  must  restructure  the  way  C  programs  are  managed 
and  resourced,  and  leadership  must  clearly  speak  out  about  their  dedication  to  achieving  an 
enterprise-wide  C  capability  at  every  opportunity.  In  this  chapter  we  have  defined  the  current 
C2  system  and  provided  a  proposal  for  how  the  Air  Force  can  achieve  an  enterprise-wide  C2 
capability  by  2005.  We  have  provided  our  views  on  areas  that  the  SAF,  Air  Staff,  and 
MAJCOM  staffs  should  focus  on  in  starting  down  a  C2  modernization  journey.  The  journey  of 
achieving  an  effective  distributed,  collaborative,  enterprise-wide  C  capability  that  allows  C 
centers  to  collaborate  globally  in  support  of  the  CINCs  is  one  of  the  most  important  journeys  the 
Air  Force  needs  to  take  in  the  21st  century. 

Reference  Appendix  2A  through  2C  for  the  C2  System  Definition  and  Operational  Concept 
Panel’s  Charter,  membership,  and  fact-finding  visit  schedule. 
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Appendix  2A 

2 

C  System  Definition  and  Operational  Concept  Panel  Charter 


Serve  as  the  focal  point  of  the  study  for  the  description  and  review  of 

•  The  current  command  and  control  concepts  and  procedures 

•  The  current  C4ISR  systems  and  their  supporting  infrastructure 

Define  the  needed  future  capability  for  command  and  control  (circa  2005)  and  develop  a  set  of 
recommendations  on  how  the  Air  Force  can  achieve  these  capabilities.  This  includes  changes  in 
the  existing  systems  or  ongoing  programs  through  the  introduction  of  new  technology  (as 
defined  by  the  Technology  Panel)  and  changes  in  training  and  personnel  policies  (as  articulated 
by  the  People  and  Organization  Panel).  Such  changes  may  require  enhancements  of  the 
acquisition  process  (as  addressed  by  the  Acquisition  and  Program  Management  Panel). 

Examine  the  command  and  control  process  both  from  the  corporate  Air  Force  level  and  from  the 
operational  level,  particularly  in  joint  and  combined  operations. 

Address  the  following  points 

•  Identify  the  Air  Force  concepts  of  operations  for  C2 

•  Identify  the  current  C2  elements  and  planned  improvements  that  will  have  an  impact  on 
operations  by  2005 

•  Identify  the  missions  the  Air  Force  is  expected  to  carry  out  in  this  timeframe 

•  Identify  the  changes  in  the  planning-execution-assessment  cycle 

Recommendations  for  the  short-term  improvements  should  be  consistent  with  the  Air  Force’s 
long-term  command  and  control  goals. 
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Appendix  2B 

C  Concept  and  System  Definition  Panel  Membership 

Lt  Gen  Joseph  E.  Hurd,  USAF  (Ret),  Chair 
Private  Consultant 

Maj  Gen  John  A.  C order,  USAF  (Ret) 

Private  Consultant 

Mr.  Troy  Crites 
Sparta,  Inc. 

Dr.  Llewellyn  S.  Dougherty 
Director  of  Technology 
Raytheon  Electronic  Systems 

Mr.  Jim  Hale 
Private  Consultant 

Maj  Gen  John  Hawley,  USAF  (Ret) 

Private  Consultant 

David  Hess 

AC2ISRC 

MITRE 

Col  Stu  Kraft,  USAF  (Ret) 

Director,  Business  Development 

Northrop  Grumman/Logicon  Technical  Solutions 

Maj  Robert  Lanahan 

Branch  Chief,  Future  Communications  Systems 
National  Reconnaissance  Office 

Prof.  Alexander  H.  Levis 
Professor 

George  Mason  University 

Prof.  Christine  Mitchell 

Professor 

Georgia  Tech 

Maj  Robin  Morris 
AC2ISRC/C2A 
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Col  Wayne  Ranne,  USAF  (Ret) 

Private  Consultant 

Col  Mike  Reavey,  USAF  (Ret) 

Private  Consultant 

Mr.  Skip  Saunders 
Executive  Director 
MITRE 

Prof.  Gene  Spafford 
Professor 
Purdue  University 

Col  Carl  Van  Pelt,  USAF  (Ret) 

Private  Consultant 

Lt  Gen  Ronald  Watts,  USA  (Ret) 

President 

Leadership  Development  Services 

Executive  Officer:  Capt  Larry  W.  Norman,  Jr.,  AC2ISRC/C2RO 
Technical  Writer:  Maj  Thomas  Schorsch,  USAFA 
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Appendix  2C 

C2  Concept  and  System  Definition  Panel  Visits 

Hurlburt  AFB,  C2TIG,  3-4  May  00 

Langley  AFB,  Air  Combat  Command,  11-13  April  00 

Nellis  AFB,  Spring  Board  Meeting,  25-27  April  00 

Las  Vegas,  Agile  Combat  Support  Conference,  May  00 

Boeing,  Seattle,  WA,  29-30  June  00 

Davis  Monthan  AFB,  7-9  June  00 

National  Reconnaissance  Office,  Capability  and  Interoperability,  16-17  May  00 
Defense  Advanced  Research  Projects  Agency,  Capabilities,  18  May  00 
Rome  Research  Site,  Capabilities,  12  June  00 
Hanscom  AFB,  Programs  Review,  13-14  June  00 
San  Diego,  C2  on  Coronado,  17  July  00 

SAB  Summer  Session,  San  Jose,  CA,  Final  Report,  10-21  July  00 
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Appendix  2D 

2 

C  Weapons  System  Management — “Matrix  Table’ 


Program 

Acquisition 

CONOPs 

ORD 

Element 

PMD 

Program  Manager  Panel  MAP /  MSP 

C4ISP 

C2  Weapon  System 

TACCS/AOC  TACCS 


AFSPACE  AOC 

ASOC _ 

BCC  (CRC/CRE) 

TACP _ 

Airborne  FAC 


AFSPACE  AOC 
TACCS / ASOC 
TACCS / BCC 
TACCS / TACP 
TACCS / FAC 


AFSPACE  AOC 

TACCS _ 

TACCS _ 

TACCS _ 

TACCS 


AFSPACE  AOC 

~ TACCS _ 

~ TACCS _ 

~ TACCS _ 

TACCS 


TACCS/AOC  CAFC2 


AFSPACE  AOC  Space  &  Nuc  Pet  C4I 

TACCS  /  ASOC  CAF  C2 _ C4I 

TACCS  /  BCC  CAF  C2 _ C4I 

TACCS  /  TACP  CAF  C2 _ C4]_ 

TACCS  /  FAC  CAF  C2  C4I 


TACCS  MAP 

Space  C2 
TACCS  MAP 
TACCS  MAP 
TACCS  MAP 
TACCS  MAP 


AOC 

AFSPACE 

AOC 

ASOC 

BCC 

TACP 

FAC 


GCCS-AF 

. a  ", 

GCCS-AF 

- - 

GCCS-AF 

GCCS-AF 

GCCS-AF 

GCCS-AF 
Integration  (CX) 

C4I 

N/A 

GCCS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCSS-AF 

GCCS-AF 
Integration  (CX) 

C4I 

ACS  MSP 

GCSS-AF 

GCCS-AF  Weapons 
Control 

GCCS-AF 

Weapons 

Control 

GCCS-AF 

Weapons  Control 

GCCS-AF 

Weapons  Control 

GCCS-AF 
Weapons  Control 

GCCS-AF 

Integration  (CX) 

C4I 

TACCS  MAP 

|C4I  Communication  &  Software  Infrastructure  Supporting  the  C2  Weapons  System 

Tactical  Comm 

Comm 

Tactical  Comm 

Tactical  Comm 

Tactical  Comm 

Infrastructure 

C4I 

Infrastructure  MSP 

multiple 

Base  Level  Comm 

Comm 

Base  Level  Comm 

Base  Level 

Comm 

Base  Level 

Comm 

Infrastructure 

C4I 

Infrastructure  MSP 

multiple 

Long  Haul  Comm 

Comm 

Long  Haul  Comm 

Long  Haul  Comm 

Long  Haul  Comm 

Infrastructure 

C4I 

Infrastructure  MSP 

multiple 

SATCOM 

Comm 

SATCOM 

SATCOM 

SATCOM 

Infrastructure 

C4I 

Infrastructure  MSP 

SATCOM 

|  Information  Infrastructure  &  Integration  of  the  C2  Weapons  System 

Common  Information 
Management  (CIM) 

CIM 

CIM 

CIM 

CIM 

GCCS-AF 
Integration  (CX) 

C4I 

Common 

Information 
Management  MSP 

N/A 

Datalinks 

CIM 

Datalinks 

Datalinks 

Datalinks 

GCCS-AF 
Integration  (CX) 

C4I 

Common 

Information 
Management  MSP 

N/A 

JNTCCS  (Joint) 

CIM 

JNTACCS  (Joint) 

JNTACCS 

GCCS-AF 

Integration  (CX) 

C4I 

Common 

Information 

Management  MSP 

N/A 

|aF  Sensors  providing  critical  information  to  the  C2  Weapon  System 

All  Sensors  (sapce, 
airborne  &  ground) 

Sensor 

Sensor 

multiple 

multiple 

multiple 

Sensor 

ISR  MAP 

One  for 

each 

Sensor 

NOTES: 


There  is  an  Aerospace  C2  CRD  over  all  the  listed  ORDs;  these  will  contain  the  total  list  of  Interoperabiltiy  KPPs  (lERs  between  nodes 


.There  is  a  capstone  PMD  over  all  the  listed  PMDs  directing  cross  program  roadmaps  to  achieve  the  CRD  capabilities 
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Chapter  3 

Report  of  the  Interoperability  Panel 


3.1  Introduction 

The  future  of  America’s  military  success,  and  thus  of  its  national  security  and  ability  to  achieve 
national  objectives,  depends  critically  on  infonnation-enabled  operations.1  Information 
dominance — the  ability  to  employ  information  to  achieve  decisive  battlespace  advantage  while 
denying  such  use  to  an  adversary — is  one  of  the  central  tenets  of  joint  doctrine,  strategy,  and 
tactics.  Achieving  this  advantage  means  that  individual  Service,  joint,  and  coalition  forces  must 
be  able  to  gather,  share,  process,  interpret,  and  use  infonnation  and  do  so  with  superior  speed, 
reliability,  security,  and  resistance  to  enemy  actions.  As  military  history  has  repeatedly  shown, 
the  side  with  an  information  advantage  will  usually  prevail,  even  against  superior  numbers.2 
This  is  increasingly  the  case  in  modern  operations  and  it  applies  to  every  level  of  the  spectrum  of 
conflict. 

Rapidly  advancing  technology — from  sensors  to  communications  to  computers  and  displays — 
provides  much  of  the  foundation  for  Information  Dominance.  Yet  decades-old  problems  with 
incompatible  equipment,  divergent  definitions  and  uses  of  data,  uncoordinated  procedures,  and 
other  aspects  of  information  sharing  continue  to  plague  U.S.  and  allied  military  forces.  We  have 
repeatedly  found  ourselves  enjoying  an  advantage  in  the  sophistication  of  our  technology,  only  to 
have  that  advantage  reduced  or  negated  by  a  lack  of  interoperability.  Recognizing  the 
seriousness  and  importance  of  this  problem,  this  Air  Force  Scientific  Advisory  Board  (SAB) 
study  has  devoted  a  specialized  panel  to  the  topic  and  charged  it  with  determining  the  sources  of 
non-interoperability  and  the  immediate  and  longer-term  steps  needed  to  correct  these  shortfalls. 

Interoperability  means  the  ability  to  link  the  right  people  and  systems,  at  the  right  time,  in  one- 
on-one,  one-to-many,  or  many-to-many  situations;  and  to  pass  consistent  data  that  converts  to 
useful  information  and  thence  to  actionable  knowledge  that  enables  cooperative  decision-making 
and  resultant  action.  A  bit  more  formally,  the  authoritative  definition  of  interoperability  is 

1.  The  ability  of  systems,  units  or  forces  to  provide  services  to  and  accept  services  from  other 
systems,  units,  or  forces  and  to  use  the  services  so  exchanged  to  enable  them  to  operate 
effectively  together.  2.  The  conditions  achieved  among  communications-electronics  systems  or 
items  of  communications-electronics  equipment  when  information  or  services  can  be  exchanged 
directly  and  satisfactorily  between  them  and/or  their  users.3 

The  key  words  are  “operate  effectively  together.”  As  we  have  learned  in  this  study,  passing 
messages  and  data  is  only  the  beginning  of  interoperability,  and  even  the  ponderous  definition 
just  cited  only  hints  at  the  complexity  of  the  problem  of  reliably  achieving  synchronized, 


1  Joint  Vision  2020,  Chairman,  Joint  Chiefs  of  Staff,  2000;  Vision  2020:  Global  Vigilance,  Reach  and  Power, 

General  Michael  E.  Ryan,  Chief  of  Staff,  U.S.  Air  Force,  and  F.  Whitten  Peters,  Secretary  of  the  Air  Force. 

2  As  one  example,  the  unauthorized  extended  absence  of  Jeb  Stuart’s  cavalry  just  prior  to  the  battle  of  Gettysburg 

deprived  Lee  of  critical  intelligence  and  is  considered  a  major  contributor  to  his  defeat.  Millennia  earlier,  Sun 
Szu  wrote,  “Act  after  having  made  assessments.  The  one  who  first  knows  the  measures  of  far  and  near  wins — 
this  is  the  law  of  armed  straggle,” — The  Art  of  War,  Thomas  Clearly,  trans.  (Boston:  Shambala  Publications 
1988). 

3  Joint  Publication  1-02,  DoD  Dictionary’  of  Military’  and  Associated  Terms. 
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mutually  supportive  action  among  elements  of  a  force.  Interoperability  has  a  myriad  of  facets, 
not  only  system  to  system,  but  also  command  to  command,  Service  to  Service,  joint  to 
component  forces,  and  joint  to  coalition  partners.  Figure  3-1,  drawn  from  the  perspective  of  a 
theater  Air  Operations  Center  (AOC),  suggests  a  few  of  the  places  where  interoperability  is 
required.  Interoperability  requirements  escalate  dramatically  when  we  look  at  joint  and  coalition 
forces  and  consider  connectivity  and  interoperability  among  service  entities  and  across  warfare 
areas.  In  combat,  the  Air  Force  works  in  the  air  superiority,  close  air  support,  and  ground  strike 
warfare  regimes  and  meet  air  mobility,  airspace  management,  aerial  refueling,  and  other 
requirements.  In  a  joint  environment,  Air  Force  units  are  joined  by  the  Navy  in  both  air 
superiority  and  ground  strike,  as  well  as  by  the  Army  and  Marine  Corps  in  ground  strike.  With 
the  burgeoning  role  of  naval  surface  and  undersea  fire  support  from  off-shore,  the  Navy’s  role  in 
ground  strike  has  now  extended  beyond  the  functions  of  Naval  Aviation,  adding  yet  another 
variable.  When  allied  forces  join  the  mix,  still  other  disconnects,  ranging  from  equipment 
peculiarities  to  differences  in  policy  and  doctrine,  can  arise  in  the  interoperability  equation  of 
joint  and  coalition  warfare. 


Figure  3-1.  Pervasive  Needs  for  Interoperability  Throughout  a  Joint/Coalition  Force 


We  have  proved  in  recent  contingencies  that  we  could  get  the  job  done  by  a  joint  force  without 
an  advanced  state  of  interoperability.  But  we  cannot  assume  that  we  can  continue  to  do  so 
indefinitely,  regardless  of  opponents  and  scenarios,  as  the  rest  of  the  world  closes  the  gap  in 
applying  information  technology  (IT)  to  warfare.  Information  dominance  will  be  increasingly 
critical  to  a  Joint  Force  Commander,  and  interoperability  is  a  prerequisite.  The  main  focus  is  on 
mission  success,  but  the  incentives  for  pursuing  joint  interoperability  range  from  minimizing  the 
cost  to  deploy,  operate,  and  support  forces  to  coping  with  the  political  and  policy  realities  of  a 
coalition.  Thus,  while  it  is  reasonable  for  the  Air  Force  to  concentrate  efforts  on  improving  the 
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interoperability  of  its  own  systems  and  units,  there  must  be  an  aggressive  parallel  effort  to 
achieve  joint  and  coalition  interoperability.  At  the  very  least,  we  must  guard  against  any  course 
of  action  that  will  further  complicate  the  joint  and  coalition  interoperability  problem. 

The  Interoperability  Panel  brought  together  both  senior  military  officers  and  technical  experts  in 
the  various  disciplines  involved.  Panel  members  included  retired  Air  Force  and  Navy  flag 
officers,  and  we  had  the  benefit  of  the  insight  of  the  Army  Science  Board  participants  in  the 
study,  while  the  chainnan  and  other  panel  members  are  active  in  interoperability  efforts 
involving  our  allies.  We  went  to  great  lengths  to  visit  the  main  organizations  working  these 
issues  in  all  three  Services  and  to  understand  their  programs  and  priorities.  In  the  sections  that 
follow,  we  present  our  analysis  of  the  technical,  operational,  organizational,  and  other  barriers  to 
interoperability  and  our  focused  recommendations  on  how  they  should  be  addressed.  Inevitably, 
many  of  our  findings  and  recommendations  overlap  those  of  other  panels  and  are  reflected  in 
their  reports  as  well. 

3.2  Approach  and  Visits 

The  panel  charter  and  membership  are  given  in  Appendices  3 A  and  3B.  The  approach  taken  by 
the  panel  to  address  these  issues  can  be  summarized  as  follows: 

•  Emphasize  contacts  with  primary  organizations  in  all  three  Services  charged  with  implementing 
interoperable  command,  control,  communication,  computer,  and  intelligence,  surveillance  and 
reconnaissance  (C4ISR)  capabilities  and  the  expertise  of  panel  members  and  other  study 
participants  with  joint  and  coalition  experience 

•  Collect  data  and  informed  opinion  on  technical,  operational,  organizational,  doctrinal  and 
procedural  aspects  of  interoperability,  especially  those  factors  that  defy  simple  solutions  through 
standardization  and  equipment  commonality 

•  Develop  insight  into  perspectives,  goals,  and  plans  affecting  interoperability  of  all  Services  and 
allied  nations 

•  Identify  key  interoperability  issues  and  assign  panel  members  to  focus  on  these;  areas  include 
information  modeling  and  engineering,  system  and  system-of-systems  architectures,  data  links 
and  other  communications,  human  factors  and  human-machine  integration,  joint  and  coalition 
interoperability,  interoperability  factors  in  system  requirements  definition  and  system  acquisition, 
ways  to  achieve  the  required  central  oversight  and  enforcement  of  interoperability  actions,  and 
long-term  strategies  to  enhance  interoperability 

•  Evaluate  the  Joint  Battlespace  InfoSphere  (JBI)  as  a  potential  solution  to  interoperability 
problems  and  the  steps  required  in  evolving  the  current  C4ISR  environment  to  the  JBI 

•  Interact  extensively  with  other  panels  to  gather  information  and  to  ensure  that  interoperability 
considerations  are  captured  in  the  overall  study 

The  panel  conducted  an  extensive  information-gathering  campaign.  The  following  is  a  synopsis 
of  the  visits,  many  of  which  were  joint  meetings  with  one  or  more  other  panels. 
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Table  3-1.  Interoperability  Panel  Visits 


Dates 

Organization/Location 

Topics 

Other  Panels 

Mar  20-21 

Command  and  Control  (C2) 
Training  and  Innovation  Group 
(C2TIG),  Hurlburt  Air  Force 

Base  (AFB) 

Aerospace  Command  and  Control  Intelligence, 
Surveillance,  and  Reconnaissance  Center 
(AC2ISRC)  story,  Electronic  Systems  Center 
(ESC)  C2  perspective,  Joint  Surveillance 

Target  Attack  Radar  System,  C2ISR 
acquisition,  C2  Battlelab,  Joint  Expeditionary 
Force  Experiment  (JEFX)  2000 

All 

April  10-12 

Joint  Forces  Command, 
AC2ISRC,  Joint  Warfare 

Center,  Joint  Battle  Center, 
Hampton,  VA 

Air  Combat  Command  (ACC)  lessons  learned, 
time-critical  targeting,  AOC  weapon  system, 

C2  tools,  data  links,  Air  Force  experimentation 

All 

April  25-27 

Red  Flag,  Nellis  AFB 

Air  Warfare  Center,  Space  Warfare  Center, 

Red  Flag,  ESC  programs,  Boeing  independent 
research  and  development 

All 

May  16-17 

National  Reconnaissance  Office 
(NRO),  Chantilly,  VA 

NRO  programs 

Technology 

May  18 

Lockheed  Martin,  Office  of  the 
Assistant  Secretary  of  Defense: 
Command,  Control, 
Communications,  and 

Intelligence  (OASD/C3!),  Joint 
Strike  Fighter  (JSF)  Program 
Office,  Crystal  City,  VA 

Project  Rainbow,  OASD/C3!  strategic  process 
improvements 

None 

June  12 

Air  Force  Research 
Laboratory/Information 

Directorate  (AFRL/IF),  Rome, 

NY 

AFRL/IF  programs 

Technology 

June  13-14 

ESC;  Woburn,  MA 

ESC  programs 

All 

June  21 

Headquarters  U.S.  Army/ 

DISC4,  Pentagon 

Army  enterprise  architecture,  Army  battlefield 
digitization,  data  models 

Technology, 
People  & 
Organization 

June  26-27 

Space  and  Naval  Warfare 

System  Command  (SPAWAR) 
System  Center,  SPAWAR 
Acquisition 

Navy  C4ISR  programs,  data  nodels,  facilities, 
architectures 

Technology 

June  30 

Army  Program  Executive 

Officers  (PEO)/C3S, 

Ft.  Monmouth,  NJ 

4 

Army  C  ISR  programs,  architectures, 
battlefield  digitization,  data  models 

None 

July  17 

USS  Coronado,  San  Diego 

Navy  command  ship  and  systems 

All 

3.3  Findings  and  Discussion 

3.3.1  The  Meaning  and  Importance  of  Interoperability 

In  introducing  this  chapter,  we  stressed  the  critical  importance  of  Information  Dominance,  and 
thus  of  interoperability,  to  success  in  current  and  future  military  operations.  To  amplify  and 
substantiate  this  general  assertion,  consider  the  following  circumstances  on  a  modem  battlefield, 
which  may  range  in  scope  from  a  major  theater  of  war  down  to  an  apartment  building  where  a 
hostage  is  imprisoned. 
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•  Unprecedented  demands  for  exquisitely  precise  application  of  military  force  are  becoming 
routine.  These  derive  from  the  needs  of  effects-based  operations,  from  the  political 
unacceptability  of  collateral  damage  and  civilian  casualties,  from  hostile  use  of  deception  and 
concealment,  and  from  many  other  factors.  The  result  is  a  critical  need  to  collect  extensive, 
current,  high-quality  information  on  targets  and  their  contexts;  to  formulate  and  distribute 
effective  mission  tasking;  to  coordinate  and  control  multiple  platforms  and  warfighters  in  tightly 
timed  sequences;  and  to  rapidly  assess  the  status  and  results  of  operations.  Each  step  of  this  chain 
demands  seamless  interoperability  across  and  within  all  echelons  of  the  force. 

•  Friendly-fire  episodes  are  among  the  most  abhorrent  events  in  war,  yet  they  persist  as  a 
consequence  of  breakdowns  in  critical  information  processes.  The  best  insurance  against  these 
tragedies  is  the  ability  to  maintain  a  comprehensive  situational  awareness  picture  of  the 
battlespace  and  to  distribute  the  appropriate  elements  of  that  picture  to  every  participant  in  real 
time.  This,  in  turn,  raises  a  typical  interoperability  challenge  that  today  is  only  partially  met. 

•  In  the  post-Cold  War  era,  no  aspect  of  military  capability,  not  even  operational  effectiveness,  is 
more  important  than  affordability.  An  obvious  cost  containment  strategy  is  to  maximize  the  use 
of  common  material  solutions  across  Services  and  allied  nations.  Yet  differences  in  policy, 
doctrine,  and  tactics  repeatedly  frustrate  this  approach.  Moreover,  failure  to  consider 
interoperability  from  the  earliest  stages  of  defining  system  requirements  and  planning  and 
executing  acquisition  programs  virtually  guarantees  later  problems,  often  with  expensive  fixes. 
These  are  interoperability  problems  as  surely  as  any  technical  incompatibility  of  equipment,  and 
may  be  harder  to  solve. 


Operational: 

Meet  Operational 
Requirements 
Define  Doctrine  & 
Tactics 

Provide  Training 
Support  Joint/ 
Coalition 
^Operations 


Policy/Procedures: 

Define  Information  Release 
Develop  Joint/Coalition  Tactics, y 
Techniques  &  Procedures 


Technical: 
Define/Implement 
Specific  Interactions 
Provide  for  LongTerm 
Evolution 


Combat  Support: 

1  Support  Expeditionar 
Forces  &  Reachback/ 
•  Work  With  All  User 
Environments 


Programmatic: 

Define  Interoperability 
Requirements 
Meet  Test/Certification 
Requirements 
Meet  Coalition  Partner^ 
^Requirements 


Figure  3-2.  Interoperability  Has  Many  Dimensions 


The  diversity  of  factors  that  must  be  harmonized  to  achieve  interoperability  is  suggested  in 
Figure  3-2.  In  joint  or  coalition  operations,  consistent  policies  and  procedures  that  enable 
sharing  and  use  of  information  across  national  and  Service  boundaries  are  essential.  For  each 
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organization  and  system,  interoperability  raises  a  wide  range  of  operational  and  support 
questions.  Finally,  in  requirements  definition  and  acquisition  processes,  interoperability 
generates  both  technical  and  programmatic  concerns.  This  last  aspect  is  especially  troublesome, 
because  interoperability  is  quintessential^  a  force  or  system-of-systems  proposition,  but  our 
approach  to  providing  systems  focuses  on  individual  programs.  Historically  program  managers 
(PMs)  have  great  difficulty  compromising  their  narrow  individual  interests  for  the  sake  of  the 
greater  good.  Conversely,  the  individual  PM  is  increasingly  seen  as  being  responsible  to  make 
interoperability  happen,  yet  the  largest  part  of  the  problem  lies  in  the  implementation  of  other 
systems  and  is  thus  beyond  the  PM’s  control.  Many  of  the  items  listed  in  Figure  3-2  are  further 
explored  in  this  and  other  chapters  of  this  report. 

These  issues  are  not  new.  The  Department  of  Defense  (DoD)  has  pursued  endless 
standardization  initiatives  in  equipment  and  procedures.  The  North  Atlantic  Treaty  Organization 
(NATO)  has  for  decades  described  rationalization,  standardization,  and  interoperability  as  a  high 
alliance  priority.  And  the  impressive  record  of  military  successes  by  the  United  States  and  our 
allies  since  Vietnam  attests  that  these  efforts  have  not  been  without  effect.  Today’s  joint  and 
coalition  forces  stand  without  peer  in  the  global  security  environment  and  are  superbly  capable, 
especially  in  large-scale  conflicts.  However,  two  things  are  different  going  forward  in  the  21st 
century.  One  is  the  exponential  growth  in  our  reliance  on  information  in  operations,  creating 
both  a  host  of  new  and  more  complex  interoperability  challenges  and  an  ever-greater  need  to 
deal  with  them.  The  other  is  the  reality  that  missions  at  the  low  end  of  the  conflict  scale — 
humanitarian  relief,  evacuations,  separation  of  hostile  parties,  and  the  like — will  be  the  most 
frequent  taskings  of  our  military  forces.  The  situational  ambiguity,  lack  of  clear  separation 
among  hostiles  and  neutrals,  limits  on  use  of  weapons,  and  other  factors  in  such  situations  place 
extreme  demands  on  enabling  information  processes  and  interoperability. 

As  the  first  step  in  dealing  with  the  interoperability  problem,  it  is  essential  that  the  meaning  of 
the  term  and  its  many  facets  and  implications  be  clearly  understood.  Like  many  other  words 
(architecture  comes  to  mind),  interoperability  means  different  things  to  various  individuals  and 
organizations 

•  To  communicators,  interoperability  usually  means  the  ability  to  connect  nodes  and  exchange 
messages.  The  key  to  this  dimension  of  interoperability  is  a  set  of  well-defined  interfaces  across 
which  interacting  information  processes  can  talk  to  each  other. 

•  To  information  technologists,  it  usually  means  the  ability  to  connect  equipment  via  networks  and 
to  have  software  applications  that  cohabitate  and  (ideally)  cooperate  when  loaded  on 
workstations,  servers,  and  nets.  The  key  here  is  control  of  the  platforms  on  which  applications 
ride,  of  the  shared  services  they  use,  and  of  the  networks  through  which  they  exchange  data. 

•  To  the  warfighter,  whose  opinion  is  the  one  that  counts,  interoperability  means  something  much 
closer  to  the  definition  given  earlier:  the  ability  to  exchange  information  in  such  a  fashion  that  it 
enables  cooperative  activities  to  accomplish  the  mission.  This  requires  that  all  aspects  of 
interoperability  be  accounted  for. 

We  have  found  that  the  best  approach  to  shed  light  on  this  complexity  is  to  construct  a  hierarchy 
of  successively  higher  levels  of  interoperability.  Figure  3-3  summarizes  this  construct. 

•  At  the  lowest  level,  interaction  requires  that  the  parties  involved  share  channels  for 
communication.  These  may  be  landlines,  voice  radios,  data  links,  satellite  communications,  or, 
for  that  matter,  couriers  on  horseback.  This  layer  is  labeled  “Connectivity”  in  the  figure,  and  it  is 
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characterized  by  the  physical  and  electronic  parameters  of  a  channel;  an  example  would  be  the 
waveform  (frequency,  modulation,  power  level,  etc.)  of  a  network  radio.  Connectivity  enables 
the  exchange  of  signals  via  data  links  or  channels. 

•  Next,  we  require  compatibility  in  the  way  these  channels  are  used  to  exchange  messages.  For  a 
voice  radio,  this  can  be  as  simple  as  a  common  language  and  a  set  of  defined  terms.  In  current 
DoD  directives,4  data  exchanges  are  specified  by  information  exchange  requirement  (IER) 
matrices,  which  specify  transactions  among  specific  platforms  and  operational  facilities  in 
response  to  particular  events.  For  a  network  or  data  link,  messaging  is  controlled  by  a  protocol 
that  governs  such  things  as  the  message  structure,  how  data  is  encoded,  how  errors  are  detected 
and  corrected,  and  how  networks  and  channels  are  managed.  A  typical  example  is  the  network 
protocol  and  J-series  messages  defined  for  Link- 16.  We  call  this  layer  “Communication,”  and  it 
enables  the  exchange  of  messages  to  achieve  shared  data. 

•  At  the  next  level  up,  the  issue  becomes  one  of  compatible  information  processes  that  ensure  that 
shared  data  is  treated  and  used  consistently.  At  this  point,  a  common  information  model, 
discussed  in  detail  later,  is  absolutely  essential.  Aspects  of  this  would  typically  include  use  of 
appropriate  elements  of  a  common  operating  picture  (COP)  via  shared  databases  and  use  of  the 
same  or  equivalent  algorithms  for  data  processing.  We  call  this  layer  “Information  Exchange,” 
and  it  results  in  shared  information  among  the  participating  information  systems. 
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•  Consistent  User  Interfaces 

•  “Brain-to-Brain”  Interaction 
SHARED  INFORMATION: 

•  Common  Operating  Pictures 

•  Common  Processes  for  Planning 

ROE,  Force  Management,  etc. 

•  Common  Data  Definitions 


/  c 

;Vi 


<0 

o 

!< 

£ 

o 

o 


V 


* 


SHARED  DATA: 

•  Info  Exchange  Requirements 

•  J-Series  &  Other  Messages 
CommonPriorities/Controls 

DATA  LINK/CHANNEL: 

•  Data  Link  Compatibility/ 

Performance 

•  Theater  Network  Participation 

INDIVIDUAL  PLATFORM/ 
SYSTEM 


Figure  3-3.  A  Hierarchy  of  Levels  of  Interoperability  Illustrates  Its  Complexity 


•  Yet  another  set  of  interoperability  factors  enters  when  we  address  the  top  layer,  involving  the 
interaction  between  information  systems  and  human  users.  This  involves  both  the  human- 
machine  interface,  especially  the  need  for  consistent  information  presentation,  and  the  underlying 
cognitive  processes  involved  in  decision  rules,  tactics,  and  training.  When  this  level  is  fully 


4  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  6212. 01B,  “Interoperability  Supportability  ofNational 
Security  Systems,  and  Information  Technology  Systems,”  May  2000. 
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achieved,  the  result  is  what  has  been  called  “brain-to-brain”  interoperability5  such  that 
commanders  and  warfighters  possess  the  common  understanding  that  enables  cooperative  action. 
Accordingly,  we  call  this  layer  “Cooperation”  and  characterize  it  in  terms  of  shared 
understanding. 

•  Finally,  true  joint  and  coalition  interoperability  demands  a  foundation  of  common  policies  and 
procedures,  drawn  in  the  figure  as  a  background  factor  spanning  the  whole  interoperability 
hierarchy.  This  goes  beyond  considerations  of  compatible  equipment  and  equivalent  tactics  and 
training.  It  involves  political  issues  of  information  release  among  nations,  unity  of  command  for 
coalition  forces,  and  shared  understanding  of  legal  constraints  and  rules  of  engagement.  With 
this,  we  have  the  kind  of  interoperability  that  modern  warfare  requires. 

There  may  be  situations  in  which  levels  of  interoperability  in  Figure  3-3  can  be  achieved  despite 
failures  or  deficiencies  in  the  layers  below.  In  general,  however,  robust  and  reliable 
interoperability  is  best  achieved  through  systematic  attention  to  building  each  level  on  a  solid 
foundation  of  the  preceding  levels,  solving  problems  a  layer  at  a  time  and  ensuring  that  all 
aspects  of  the  problem  are  addressed  in  due  sequence. 

3.3.2  Typical  Interoperability  Problems 

To  make  the  somewhat  abstract  discussion  of  the  introductory  section  more  concrete,  we  have 
compiled  a  few  real-world  examples.  Lessons  learned  from  Operation  Allied  Force6  and  other 
recent  operations,  exercises,  and  experiments  illustrate  the  kinds  of  non-interoperability  with 
which  this  chapter  is  concerned.  Some  problems  are  susceptible  of  relatively  near-tenn  and 
inexpensive  fixes,  while  others  will  require  anything  from  system  acquisitions  and  modifications 
to  resolution  of  national  information  policy  issues.  A  few  representative  problem  areas  are  listed 
below  to  give  a  sense  of  the  situation,  along  with  some  candidate  near-term  actions  to  address 
them.  More  pervasive,  longer-tenn  approaches  are  addressed  in  later  sections  of  this  chapter. 

•  Inadequate  Secure  Communications.  The  coalition  force  operating  in  Kosovo  found  that 
secure  communications  were  sometimes  not  adequate,  in  part  due  to  the  greater  level  of  technical 
sophistication  of  U.S.  systems.  Near-term  fix:  Work  with  allies  to  deploy  additional  secure  radio 
frequency  (RF)  and  landline  communications  assets,  including  attention  to  a  coalition  encrypted 
Link- 16  capability. 

•  Separate  U.S./Coalition  C2  Networks.  Policy  issues  affecting  information  sharing  with  allies 
caused  a  number  of  problems.  NATO  secure  networks  proved  incapable  of  handling  heavy 
traffic  such  as  the  air  tasking  order  (ATO)  until  a  work-around  involving  a  scheme  to  tunnel  the 
traffic  through  other  secure  channels  was  devised.  Similarly,  separate  U.S. -only  and  coalition 
ATOs  were  required,  which  created  additional  work  and  slowed  dissemination  of  C2.  Near-term 
fix:  Resolve  information  release  policy  issues  and  publish  a  single  ATO,  with  a  U.S. -only  annex 
if  required  for  specific  content.  Work  with  allies  to  deploy  higher  capacity  secure  networks  and 
to  implement  guards  and  other  measures  as  required  to  allow  connectivity. 

•  Inadequate  Management  of  Network  Bandwidth  and  Spectrum.  Central  coalition 
management  of  limited  network  capacity  and  spectrum  allocations  continued  to  be  a  problem,  as 
in  earlier  operations.  Multiple  approvals,  each  taking  time,  were  required  to  use  needed 
frequencies.  Near-term  fix:  Develop  and  implement  improved  tools  and  procedures,  including 


5  Julian  Ranger,  Through  Life  Interoperability’  Program  (TULIP)  Handbook,  STASYS,  Ltd.,  1999. 

6  Initial  Report:  the  Air  War  over  Serbia,  Aerospace  Power  in  Operation  Allied  Force,  United  States  Air  Forces  in 

Europe,  Studies  and  Analysis  Directorate,  April  2000. 
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use  of  available  systems  for  monitoring  and  managing  Link- 1 6  and  other  key  data  links,  and  pre¬ 
coordination  of  spectrum  allocation  with  host  nations. 

•  Incompatible  U.S./Coalition  Systems  in  the  Coalition  Air  Operations  Center  (CAOC).  The 

U.S.  employs  the  Contingency  Theater  Air  Planning  System,  and  is  moving  toward  the  even  more 
sophisticated  Theater  Battle  Management  Core  System  (TBMCS),  while  NATO  uses  different 
systems  with  a  number  of  incompatibilities.  This  hindered  coordination  among  coalition  forces. 
Near-term  fix:  Work  with  allies  to  establish  better  collaboration  tools  and  procedures,  including 
automated  translation  of  files  and  messages  to  bridge  system  incompatibilities,  and  use  exercises 
to  better  define  problems  and  identify  solutions. 

•  Incompatible  Procedures  for  the  Same  Aircraft  or  Weapons.  In  some  cases,  air  forces 
employing  the  same  systems  had  evolved  different  tactics  and  procedures,  complicating 
cooperative  operations.  Near-term  fix:  Use  joint  and  coalition  exercises,  training  and  operations 
to  develop  common  tactics,  techniques,  and  procedures  (TTPs). 

•  Multiple  Specific  Disconnects.  A  number  of  specific  problems  have  been  identified,  including 
inconsistent  time  references  for  Link- 16  messages,  inconsistent  callouts  from  identification 
systems,  limited  interoperability  of  ground  force  and  aircraft  radios,  and  many  others.  Near-term 
fix:  Case  by  case  basis,  clearly  define  the  problem  and  seek  affordable  (especially  through 
procedure  changes)  corrective  actions. 

3.3.3  Interoperability  and  the  Expeditionary  Aerospace  Force  (EAF) 

The  Air  Force  is  well  along  in  transitioning  to  the  EAF  and  now  plans  to  go  to  war  using 
Aerospace  Expeditionary  Forces  (AEF).  This  concept  of  operations  (CONOPS),  when  fully 
developed,  calls  for  the  Air  Force  to  deploy  a  precisely  tailored  force,  including  the  required 
communications,  in  as  little  as  24  to  48  hours  to  meet  national  requirements.  This  poses 
enonnous  interoperability  challenges.  Training  and  maintenance  are  still  done  by  Numbered  Air 
Forces  (NAFs)  using  procedures  that  are  often  peculiar  to  a  particular  theater,  while  the  AEF  that 
goes  to  war  is  likely  to  consist  of  units  chosen  from  various  NAFs.  It  is  vital  that  the  various 
units  of  an  AEF  be  interoperable,  including  all  aspects  addressed  in  Section  8. 1,  in  order  to  be 
ready  to  generate  sorties  and  operate  as  a  cohesive  force  immediately  upon  arrival  in  theater.  It 
would  be  highly  desirable  as  part  of  the  work-up  to  an  AEF’s  window  of  vulnerability  for 
deployment  to  ensure  that  the  infonnation  systems,  TTPs,  support  systems,  and  other  essential 
assets  are  fully  compatible.  In  the  long  term,  the  JBI  construct  greatly  simplifies  this  problem, 
but  the  Air  Force  requires  a  near-tenn  solution  as  well. 

The  Navy  faced  a  similar  problem  in  dealing  with  the  ships  that  form  a  battle  group  and  found 
that  they  sometimes  went  to  sea  with  incompatible  systems.  To  solve  this  problem,  the  Navy 
developed  the  Distributed  Engineering  Plant  (DEP),  a  network  of  simulation  facilities  to  test  the 
interoperability  of  the  systems  installed  on  the  ships,  with  the  software  load  that  is  heading  for 
sea,  before  the  battle  group  sails.  We  recognize  that  the  AEF  problem  differs,  primarily  because 
the  AEF  has  a  more  flexible  schedule.  The  Navy  battle  group’s  composition  and  departure  date 
are  known  well  in  advance.  The  AEF  may  be  dynamically  configured  on  24  hours’  notice. 
However,  there  is  a  rough  equivalent  in  the  3 -month  deployment  vulnerability  window  through 
which  the  AEFs  rotate.  Interoperability  of  like  wings  within  the  AEF  is  tested  during  the 
6-month  Normal  Operations  Phase  II.  The  AOC,  lead  wings,  assigned  wings  and  squadrons,  and 
the  associated  lead  mobility  wings  should  be  tested  in  a  DEP-like  facility  before  beginning  the 
6-week  schedule  of  exercises  in  the  work-up  phase.  This  facility  should  also  simulate  standing 
AOCs,  with  which  the  AEF  will  most  likely  operate.  This  will  enable  the  exercises  to  be  used  to 
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train  the  people  and  check  out  the  procedures,  rather  than  to  verify  the  interoperability  of  the 
equipment.  A  DEP-like  facility  should  also  simulate  low-density,  high-demand  assets  for 
interoperability  tests.  Ideally,  such  a  facility  would  also  simulate  the  elements  of  other  services 
with  which  the  AEF  will  most  likely  interact.  In  our  recommendations,  we  offer  a  specific 
approach  to  achieve  this  through  a  “Distributed  C4ISR  Simulation  Network.” 

AEF  interoperability  extends  to  more  than  Air  Force  airplanes  and  command  centers.  Long-haul 
communication  for  reachback  to  home  theaters  is  likely  to  require  that  communications  assets 
deploy  even  before  combat  forces.  Depending  on  the  level  of  development  of  the  countries  and 
bases  hosting  the  AEF,  this  may  entail  considerable  equipment  and  require  interoperability  with 
a  wide  variety  of  space  and  terrestrial  communications  infrastructure.  Ideally,  both  routine 
training  and  preparation  for  an  actual  deployment  should  include  work  with  joint  and  coalition 
forces  likely  to  be  involved. 

The  Office  of  the  Secretary  of  Defense,  Under  Secretary  for  Acquisition  and  Technology  and  the 
Joint  Staff  J-8  have  established  a  program  to  develop  a  Joint  Distributed  Engineering  Plant 
(JDEP),  but  that  program  has  been  underfunded.  The  joint  group  has  also  begun  to  explore  the 
Joint  Theater  Air  and  Missile  Defense  mission.  The  Air  Force  should  either  create  a  Program 
Objective  Memorandum  (POM)  for  the  JDEP  and  ensure  that  it  meets  the  needs  of  the  EAF,  or 
develop  an  Air  Force  facility  like  the  Distributed  C4ISR  Simulation  Network  to  meet  the  needs 
of  the  AEFs  and  plan  to  eventually  tie  it  to  the  JDEP.  Facilities  that  would  be  candidates  for 
integration  into  a  JDEP  network  include  those  of  the  C"TIG,  the  ESC  C  Unified  Battlespace 
Environment  (CUBE)  and  the  Theater  Air  C2  Support  Facility  (TACCSF),  as  well  as  new 
facilities  like  the  proposed  experimental  C2  centers  at  Langley  and  Nellis  AFBs. 

3.3.4  Joint  and  Coalition  Interoperability 

Following  the  Panel  Charter,  we  have  devoted  considerable  attention  to  the  subject  of  joint  and 
coalition  interoperability.  In  addition  to  the  discussion  below,  Section  2.6.9  of  the  Concept  and 
System  Definition  Panel  Report  in  the  previous  chapter  highlights  some  of  today’s  most  critical 
operational  interoperability  problems.  The  primary  focus  of  this  study  is  on  Air  Force  problems, 
processes  and  systems,  with  a  goal  of  having  the  Air  Force  “linked  by  2005.”  However,  almost 
any  foreseeable  combat  operation,  and  many  humanitarian  and  peacekeeping  missions,  will 
involve  joint  or  coalition  forces.  Thus,  while  the  C"  interoperability  challenge  within  the  Air 
Force  alone  is  significant,  the  effort  must  clearly  be  extended  to  the  total  ensemble  of  forces 
involved  in  an  operation.  It’s  difficult  to  imagine  a  scenario  where  the  operational  limitations 
created  by  a  lack  of  interoperability,  as  we  know  them  today,  can  be  solved  by  even  perfect  Air 
Force  interoperability.  The  task  of  achieving  an  interoperable  joint  or  coalition  force  is  daunting 
and  has  proved  intractable;  it  impacts  everything  from  doctrine  and  national  policy  to  systems, 
processes,  procedures,  and  missions.  Success  in  coalition  operations  will  often  yield  important 
political  and  diplomatic  benefits  and  may  be  essential  due  to  the  need  for  an  international 
mandate  and  for  geographic  access. 
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33.4.1  A  Problem  with  Many  Dimensions 

Interoperability  in  general,  but  especially  in  the  context  of  joint  and  coalition  operations,  is 
impacted  by  virtually  every  aspect  of  the  forces  involved,  including 

•  The  Operational  Dimension:  policy  and  doctrine,  training,  the  requirements  process,  and  rules 
for  the  conduct  of  joint  and  coalition  operations 

•  The  Technical  Dimension:  performance  capabilities  of  various  systems,  conformity  to  interface 
standards  and  common  procedures,  information  assurance,  and  overall  levels  of  technical 
sophistication  of  participating  forces 

•  The  Programmatic  Dimension:  specification  and  fielding  of  interoperable  systems, 
interoperability  testing  and  certification,  and  resolution  of  interoperability  issues  involving 
multiple  systems  and  agencies 

•  The  Support  Dimension:  compatibility  of  weapon  systems  and  multiple  support  environments, 
especially  under  deployed  and  austere  conditions 

As  summarized  in  Section  3.3.2,  recent  contingencies,  as  well  as  tests,  exercises,  and 
experiments,  have  uncovered  deficiencies  and  illustrated  the  consequences  of  joint  or  coalition 
interoperability  shortfalls.  To  choose  one  example  among  many,  ambiguous  “identification, 
friend,  foe,  or  neutral”  declarations,  as  were  identified  in  a  1994  Link- 16  test  at  Mountain  Home 
AFB,  can  have  a  debilitating  impact  on  rules  of  engagement  (ROE)  and  the  success  of  the  air 
war.  When  System  “A”  can  flag  targets  as  “friendly,”  “presumed  friendly,”  “unknown,” 
“presumed  hostile,”  and  “hostile,”  and  System  “B”  has  only  “friendly,”  “unknown,”  and 
“hostile,”  then  system  “A”  displays  “presumed  friendly”  as  “unknown.”  At  a  minimum,  the 
result  is  confusion  in  what  should  be  a  simple  task  of  handling  a  common  track.  More  seriously, 
it’s  easy  to  envision  this  situation  leading  to  fratricide  or  to  a  friendly  aircraft’s  being  surprised 
by  a  hostile.  In  another  case,  lessons  learned  from  the  Kosovo  operation  show  that  various 
Link- 16  terminals  that  comply  with  the  applicable  Standardization  Agreement  nevertheless  had 
incompatibilities  that  prevented  correct  information  exchange  due  to  such  problems  as 
inconsistent  definitions  of  the  time  stamp  incorporated  in  a  report.  The  overall  message  is  that 
interoperability  problems  are  numerous,  often  subtle,  and  frequently  difficult  to  diagnose  and 
correct. 

It’s  difficult  to  set  the  right  boundaries  on  interoperability  requirements,  largely  because  it’s 
impossible  to  predict  the  next  fight.  Which  forces  from  which  Services  and  nations  will 
participate  in  which  roles  are  matters  unlikely  to  be  settled  until  after  a  crisis  erupts.  Moreover, 
the  need  for  interoperability  increasingly  extends  to  non-Defense  government  entities  (such  as 
the  Department  of  State,  Coast  Guard,  and  Department  of  Transportation)  and  even  to  non¬ 
government  organizations  (NGOs),  especially  in  humanitarian  missions.  A  prime  requirement  is 
thus  that  joint  and  coalition  interoperability  be  general  and  robust,  not  requiring  the  kind  of  ad 
hoc  work-arounds  that  have  been  used  to  patch  disconnects  in  recent  engagements  and  not 
assuming  that  any  single  country  or  Service  has  sole  responsibility  to  correct  interoperability 
problems.  Platforms  should  be  able  to  communicate,  command  centers  should  be  able  to 
exchange  classified  infonnation,  and  commanders  should  have  a  shared  and  consistent  view  of 
the  situation,  regardless  of  which  systems  are  in  use  or  who  provides  them.  Today,  the  U.S. 
anned  forces  and  their  allies  are  far  from  that  ideal. 

Difficulties  in  interoperability  with  coalition  partners  become  evident  every  time  we  operate 
together  or  conduct  a  joint  or  combined  exercise.  We  learn  the  lessons  over  and  over,  yet  too 
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often  seem  unable  to  acquire  systems,  develop  TTPs,  establish  compatible  support  environments, 
and  conduct  training  so  as  to  achieve  the  required  level  of  interoperability.  To  take  a  simple  but 
suggestive  example,  when  something  as  basic  as  a  secure  telephone  is  procured  as  a  NOFORN 
(U.S.-only)  system,  an  obvious  and  powerful  instrument  of  interoperability  is  frustrated. 

This  is  not  to  ignore  the  reality  that  some  information,  and  even  some  technology  and  systems, 
will  not  be  shareable  with  our  allies.  But  such  decisions  must  be  balanced  against  the 
overarching  need  for  interoperability,  and  effective  means  to  command,  control  and  support  a 
joint  or  coalition  force  must  be  assured.  To  return  to  the  CAOC  example  cited  earlier  from 
Operation  Allied  Force,  where  we  were  operating  with  primarily  NATO  allies  (when  the  United 
States  decides  to  release  sensitive  information,  it’s  safe  to  say  that  NATO  countries  get  it  first), 
we  found  the  need  to  restrict  ATO  information  on  selected  systems.  The  Joint  Force  Air 
Component  Commander  (JFACC),  Lt  Gen  Michael  Short,  needed  as  always,  to  get  the  tasking, 
Airspace  Control  Order  (ACO),  Special  Instructions,  and  other  C  infonnation  to  ah  the  forces  in 
the  coalition.  He  later  said  that  there  was  nothing  that  could  not  have  been  handled  by  a  U.S.- 
only  cell  within  the  CAOC,  and  that  we  should  never  again  publish  separate  ATOs.  Information 
exchanges  that  cross  boundaries  between  differing  levels  of  classification  will  be  a  continuing 
challenge,  but  a  combination  of  technical,  procedural,  and  policy  measures  must  be  employed  to 
simultaneously  ensure  information  security  and  provide  timely  and  robust  interaction  within  the 
elements  of  the  force. 

Infonnation  release  is  essentially  a  policy  issue,  but  its  resolution  needs  to  be  complemented  by 
technical  solutions  that  ensure  that  coalition  secure  systems  have  adequate  capacity  and  that 
measures  such  as  software  guards  to  isolate  computing  environments  at  different  levels  of 
classification  are  used  when  appropriate.  The  key  to  success  is  to  develop  C2  systems  that  are 
flexible  enough  to  interface  with  other  agencies  and  able  to  protect  classified  infonnation  in  such 
interactions,  together  with  information  release  rules  and  procedures  that  account  for  the 
operational  realities  of  employing  joint  and  coalition  forces.  Such  a  strategy  can  only  succeed  if 
it  is  rooted  in  an  architecture  that  establishes  the  information  structure  to  which  the  elements  of  a 
joint/coalition  force  must  confonn  and  the  interfaces  across  which  information  is  exchanged. 
Much  of  the  remainder  of  this  chapter  is  devoted  to  various  facets  of  C2  architecture  and  its 
implementation. 

There  are  additional  constraints  on  achieving  joint  or  coalition  interoperability  that  are  inherent 
in  the  way  the  United  States  and  its  allies  acquire  systems.  Some  can  be  overcome,  and  some 
probably  cannot.  First,  and  perhaps  foremost,  is  the  system-centric  approach  to  acquisition. 
Historically,  the  focus  in  ah  Services  has  been  to  get  the  operational  capability  of  a  system 
fielded  with  little  or  no  regard  for  interoperability  with  the  rest  of  the  force.  Interoperability  has 
not,  until  quite  recently,  been  a  key  performance  parameter  (KPP).  Legacy  systems  present  a 
bewildering  array  of  interfaces,  and  often  require  gateways  to  allow  infonnation  exchange. 
Force-level  architecture  has  consisted  of  little  more  than  a  catalog  of  standards,  and  competitive 
pressures  have  given  industry  an  incentive  to  deliver  closed,  proprietary  systems.  Technology 
transfer  issues  and  additional  proprietary  issues  relating  to  foreign  industry  hinder  coalition 
interoperability  solutions.  Compliance  mechanisms  for  interoperability  with  enforcement  power 
from  the  requirements  definition  stage  through  production  and  delivery  of  systems  have  been 
lacking.  Cost  is  often  cited  as  a  rationale  to  compromise  interoperability  because  there  is  no  way 
to  account  for  economic  impacts  at  any  level  other  than  an  individual  system  or  program.  In 
short,  the  entire  system  development  process  conspires  against  interoperability. 
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3. 3. 4.2  Interoperability  Initiatives 

Even  so,  some  recent  initiatives  offer  hope.  DoD  has  developed  a  C4ISR  Architecture 
Framework7  that  establishes  the  construct  of  operational,  technical,  and  system  views  of  an 
architecture,  which  may  apply  to  a  system,  a  family  of  systems  or  a  system  of  systems 
(Figure  3-4).  Each  view  is  defined  by  a  set  of  mandatory  and  optional  products.  The  framework 
also  provides  common  definitions,  and  common  references  (building  blocks),  for  example,  the 
Uniform  Joint  Task  Fist,  Shared  Data  Environment,  Technical  Reference  Model,  Joint  Technical 
Architecture,  and  the  Defense  Data  Dictionary  System.  The  framework  provides  a  basis  for 
attacking  the  architecture  problems  described  above.  The  Joint  Staff  is  drafting  a  Joint 
Operational  Architecture  (JOA),  supported  by  a  set  of  Joint  Mission  Architectures  (JMAs).  If 
carefully  developed  and  rigorously  applied,  these  may  be  important  elements  in  a  broad 
interoperability  strategy,  initially  for  U.S.  forces  and  potentially  with  allies. 

DoD  policy  has  established  interoperability  as  a  KPP,  and  CJCSI  62 12.0 IB  spells  out  the 
process,  roles  and  responsibilities  of  the  Defense  Information  Systems  Agency  (DISA), 
especially  the  Joint  Interoperability  Test  Center  (JITC),  the  Joint  Staff,  and  the  Services  in 
achieving  interoperability  certification  for  new  systems.  The  instruction  places  heavy  emphasis 
on  proper  treatment  of  interoperability  in  requirements  definition  and  on  the  application  of  the 
C4ISR  Architecture  Framework.  The  approach  is  centered  on  the  definition  of  a  set  of  critical, 
top-level  IERs,  and  the  limitations  of  this  view  of  interoperability  are  discussed  in  a  later  section 
of  this  chapter. 

DoD’s  grand  strategy  for  achieving  Information  Dominance  is  the  Global  Information  Grid 
(GIG) — the  overall  Defense  Transformation  Initiative  aimed  at  providing  the  information 
infrastructure  required  by  U.S.  forces  in  the  21st  century.  It  responds  to  the  Clinger-  Cohen  Act 
of  1996,  to  various  mandates  for  Defense  reform,  and  to  the  concept  of  Information  Dominance 
in  Joint  Vision  2010  and  Joint  Vision  2020  (JV2010  and  JV2020).  The  JOA  is  being  defined  as 
the  Operational  Architecture  View  of  the  GIG.  The  Deputy  Secretary  of  Defense  recently  issued 
a  GIG  Guidance  and  Policy  Memorandum.8  This  directive  provides  for  the  GIG  “as  a 
cornerstone  in”  DoD’s  “Revolution  in  Military  Affairs,  the  Revolution  in  Business  Affairs,  and 
in  enabling  the  achievement  of  Information  Superiority.”  A  GIG  Capstone  Requirements 
Document  (CRD)  has  been  drafted  by  U.S.  Joint  Forces  Command.  The  GIG  is  defined  as  “the 
globally  interconnected,  end-to-end  set  of  information  capabilities,  associated  processes,  and 
personnel  for  collecting,  processing,  storing,  disseminating  and  managing  information  on 
demand  to  warfighters  policy  makers  and  support  personnel.”  Both  an  overall  vision  and  a  GIG 
Systems  Reference  Model  have  been  developed. 


1  DoD  (JlSR  Architecture  Framework,  Version  2,  18  Dec  1997. 

8  DoD  CIO  Guidance  and  Policy  Memorandum  8-8001,  March  31,  2000 — Global  Information  Grid. 
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Figure  3-4.  Three  Views  That  Define  an  Architecture 


OASD/C  ’I  has  been  designated  DoD’s  Chief  Information  Officer  (CIO),  and  CIOs  have  also 
been  designated  for  the  Services,  Unified  Commands,  and  major  Defense  Agencies.  A  CIO 
Executive  Board  was  also  mandated  by  the  Act.  Under  Title  10  U.S.  Code,  Section  2223,  as 
amended  by  Clinger-Cohen,  the  DoD  CIO  has  statutory  authority  to  make  and  approve  IT  budget 
requests,  ensure  IT  interoperability,  ensure  application  of  standards,  and  eliminate  duplication. 
Overall,  the  DoD  CIO  community  may  provide  an  important  forum  and  mechanism  for  attacking 
the  problems  that  have  bedeviled  joint  interoperability.  OASD/C  I  is  revising  the  applicable 
policy  documents  and  has  under  way  a  wide  variety  of  activities  aimed  at  various  aspects  of 
interoperability.  JITC  has  extensive  experience  in  working  interoperability  problems,  possesses 
valuable  facilities  for  testing,  and  has  taken  a  proactive  stance  in  working  with  programs  to 
address  interoperability  requirements.  A  less  formal  but  nonetheless  effective  forum  for  working 
interoperability  issues  has  been  formed  by  the  concerned  PEOs  of  the  three  Services. 

Today,  the  GIG  is  conceptual,  but  as  it  is  implemented  in  operational  architectures,  acquisition 
programs,  and  other  concrete  measures  affecting  DoD  information  systems,  it  may  help  to 
provide  the  “big  picture”  within  which  legacy  stovepiped  systems  can  move  toward  the  required 
levels  of  integration  and  interoperability.  The  scope  and  purpose  of  the  GIG  substantially 
overlap  those  of  the  JBI  (Chapter  8),  and  it  seems  likely  that  the  JBI,  which  is  better  defined  and 
more  in  tune  with  modern  technology  than  the  GIG,  will  supplant  it  over  time. 

Finding  affordable  ways  to  improve  the  interoperability  of  legacy  systems,  as  well  as 
overcoming  inertia  and  parochialism  within  Services  and  their  programs,  remain  as  challenges. 
However,  interoperability  is  receiving  unprecedented  attention,  and  the  creation  of  the  KPP 
provides  a  badly  needed  incentive  for  individual  PMs  to  treat  interoperability  with  the  priority  it 
deserves. 
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3. 3. 4.3  Air  Force-Army  Interoperability  Issues 

Close  linkage  between  air  and  ground  forces  is  obviously  essential  to  mission  success  and 
fratricide  prevention.  Both  C2  centers  and  individual  units  and  platforms  are  involved.  The 
Army  Battle  Command  System  (ABCS)  in  a  Tactical  Operations  Center  must  interact  closely 
with  the  TBMCS  in  an  AOC.  Currently,  coordination  is  accomplished  through  a  collocated 
Battlefield  Coordination  Detachment  (BCD)  in  the  AOC,  and  Army  deep  operations  planning 
and  execution  require  timely  information  exchanges  among  the  Deep  Operations  Coordination 
Center  (DOCC),  the  AOC  (through  the  BCD)  and  the  Air  Support  Operations  Center  (ASOC). 
Progress  has  been  made,  but  a  number  of  interoperability  issues  remain. 

ABCS  components  that  require  interoperability  in  various  forms  with  the  Air  Force  C2 
environment  include 

•  Global  C2  System-Army  (GCCS-A):  GCCS-A  is  the  Army  component  of  the  GCCS  initiative. 
It  provides  automated  C2  tools  to  enhance  warfighter  capabilities  during  joint  and  combined 
operations. 

•  Maneuver  Control  System  (MCS):  MCS  is  the  battle  command  system  for  the  maneuver 
commander  and  operational  staffs.  It  provides  the  common  tactical  picture,  planning  aids  and 
battle  tracking  and  execution  capabilities.  Its  products  include  friendly  unit  locations,  operational 
plans,  and  other  operational  data  essential  for  battlespace  awareness. 

•  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS):  AFATDS  is  the  fire  support 
component  of  the  ABCS.  It  provides  tools  for  planning,  coordination  and  control  of  fire  support 
assets. 

•  All  Source  Analysis  System  (ASAS):  ASAS  is  the  intelligence  electronic  warfare  element  of 
ABCS.  It  is  the  primary  intelligence  tool  at  battalion  through  coips  levels  to  fuse  multi-source 
information  into  a  single  threat  picture.  It  compiles  intelligence  information  into  databases  that 
support  intelligence  preparation  of  the  battlefield  (IPB),  situational  awareness,  and  target 
nomination. 

•  Tactical  Airspace  Integration  System  (TAIS):  TAIS  is  an  information  management  system 
that  supports  Army  Airspace  C2  at  coips,  divisions,  and  BCD. 

•  Automated  Deep  Operations  Coordination  System  (ADOCS):  The  Army  has  developed 
ADOCS  as  a  management  tool  to  coordinate  deep  operations.  ADOCS  enables  accelerated 
mission  planning  and  airspace  coordination.  It  could  be  integrated  with  the  ATO  databases. 
ADOCS  is  interoperable  with  GCCS,  GCCS-A,  AFATDS,  ASAS,  and  ADA.  Third  Army  (Army 
Forces  Central  Command)  is  evaluating  its  potential  to  support  joint  warfighting. 

•  Air  Mission  Planning  System  (AMPS):  AMPS  provides  a  capability  to  rapidly  transmit  Army 
aviation  air  routes  and  other  functions  to  TAIS.  The  ground  liaison  officer  and  the  suppression  of 
enemy  air  defenses  (SEAD)  squadron  can  use  it  to  see  the  Army  aviation  air  routes  and  changes 
that  may  be  made  to  them  while  helicopters  are  en  route. 

The  Air  Force  TBMCS  and  Army  Project  Managers  for  GCCS-A,  ASAS,  AFATDS,  and  the  Air 
Missile  Defense  Work  Station  (AMDWS)  signed  an  Interface  Control  Document  (ICD)  in  1998. 
Below  is  a  summary  of  the  situation: 

•  TBMCS — GCCS-A:  The  ICD  calls  for  interfacing  via  exchange  of  U.S.  Message  Transmission 
Format  (USMTF)  messages.  The  current  plan  is  to  use  the  2000  version  of  USMTF.  GCCS-A 
interfaces  with  TBMCS  to  provide  target  nomination.  The  ATO  and  ACO  are  provided  from 
TBMCS  to  GCCS-A. 
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•  TBMCS — MCS:  The  MCS  contract  specifications  include  a  requirement  for  MCS  interface 
with  TBMCS.  Specifics  of  how  this  interface  will  occur  need  resolution. 

•  TBMCS— AFATDS:  AFATDS  interfaces  with  TBMCS  at  the  AOC  and  the  ASOC.  The 
interchange  will  be  via  USMTF  or  USMTF-like  messages.  This  issue  is  assessed  as  yellow, 
turning  green  when  TBMCS  is  fully  developed  and  fielded. 

•  TBMCS — ASAS:  ASAS  interfaces  with  TBMCS  at  the  AOC.  ASAS  will  exchange  intelligence 
information  through  the  Modernized  Integrated  Database  (MIDB)  upon  completion  of  ASAS  6.2 
in  September  2000.  Should  this  approach  not  work,  there  needs  to  be  a  direct  interface  to  support 
en  route  aircraft  retasking. 

•  TBMCS — AMDWS:  TBMCS  will  exchange  data  with  a  single  designated  AMDWS.  The 
designated  AMDWS  will  further  distribute  the  ATO  and  ACO. 

•  TBMCS — TAIS:  These  systems  are  not  interoperable.  TAIS  has  demonstrated  that  it  can 
exchange  USMTF  ATO  and  ACO  messages  with  TBMCS.  The  PM  for  Air  Traffic  Control 
acknowledges  the  requirement  for  TAIS  to  be  interoperable  with  TBMCS.  TAIS  is  implementing 
the  Joint  Common  Data  Base  and  should  then  be  interoperable. 

Specific  issues  that  need  attention  include 

•  Disconnects  between  TBMCS  and  ABCS  that  inhibit  dynamic  targeting  and  real-time  force 
coordination  must  be  resolved.  If  the  GCCS  vision  of  a  real-time  COP,  or  Family  of  Integrated 
Operational  Pictures  (FIOP),  is  realized,  it  will  support  database-to-database  interactions  and  help 
ensure  consistent,  timely  views  of  the  battlespace  by  both  air  and  land  commanders.  An 
important  aspect  of  this  is  timely  exchange  of  intelligence  information;  an  example  would  be  use 
of  ASAS  feeds  in  the  AOC  process  for  IPB.  Another  is  the  need  for  current,  accurate  friendly 
force  locations  in  the  situational  awareness  picture  in  the  AOC  and  in  Air  Force  cockpits. 

•  Better  means  are  needed  for  dynamic  tasking  and  cross-cueing  of  Air  Force  and  Army 
intelligence,  surveillance  and  reconnaissance  (ISR)  assets  to  locate  and  identify  targets.  For 
example,  the  AOC  collection  manager  should  have  a  data  link  to  the  DOCC  to  nominate  targets 
and  allow  cross-cueing  of  Army  ISR  assets  (for  example,  GUARDRAIL  Common  Sensors  and 
Fire  Finder  radars).  Likewise,  the  DOCC  should  have  a  data  link  to  the  AOC  for  tasking  Air 
Force  assets.  Procedures  should  support  dynamic  retasking  of  collection  assets  to  support  real¬ 
time  targeting. 

•  The  ATO  process  and  timeline  need  to  better  support  Army  flight  operations.  The  Air  Force, 
Navy,  and  Marine  Corps  control  aircraft  operations  by  tail  number.  In  contrast,  Army  aviation 
assets  are  controlled  by  unit  assignments.  The  current  72-hour  ATO  cycle  is  too  long  and 
inflexible  to  accommodate  Army  flight  operations.  In  addition  preplanned,  deliberate  Army 
flying  missions  that  cross  the  forward  line  of  troops  (FLOT),  including  deep  attack  and  air  assault 
missions  should  be  in  the  ATO  to  ensure  search  and  rescue  and  SEAD  support.  Better 
deconfliction  of  airspace  and  missions  is  another  important  consideration. 

•  The  AOC  needs  better  means  to  initiate  and  control  attack  of  mobile  targets.  Currently,  Desired 
Mean  Points  of  Impact  (DMPIs)  are  required  to  put  a  target  on  the  draft  Joint  Integrated 
Prioritized  Target  List  and  Target  Nomination  List.  Mobile  targets  do  not  have  DMPIs  in  a 
prepared  database  like  fixed  targets  do  in  the  MIDB.  Currently,  in  exercises,  the  BCD  must 
create  DMPIs  for  mobile  nominations,  which  is  a  time-consuming  process.  It  will  be  impossible 
to  add  DMPIs  in  a  real-world  situation  where  the  ground  forces  may  nominate  dozens  of  targets. 

•  AFATDS  interoperability  with  TBMCS  at  both  the  AOC  and  the  ASOC  is  essential  for 
integrating  battle  plans  and  coordinating  situational  awareness.  Air  Force  and  Army  plans  call 
for  TBMCS — AFATDS  interoperability  via  eight  different  USMTFs  that  focus  on  targeting  and 
friendly  unit  information.  AFATDS  should  be  able  to  dynamically  retask  assets  to  facilitate  the 
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attack  of  time-critical  targets.  By  implication,  close  coordination  between  ABCS  systems  and  the 
Battle  C  ommand  C  enter  of  the  next-generation  Air  Force  C2  structure  will  be  essential. 

•  Close  air  support  (CAS)  forces  must  have  improved  situational  awareness  to  understand  the 
dynamics  of  mobile  ground  operations.  A  key  deficiency  in  air-to-ground  operations  is  that 
ground  forces  are  not  visible  in  the  Joint  Data  Network  (JDN) — the  joint  tactical  data  link  that 
enables  all  participants  in  a  theater  air  defense  organization  to  create  the  single  integrated  air 
picture,  manage  air  and  maritime  battlespace,  and  conduct  identification — friend  or  foe.  One 
approach  might  be  a  gateway  between  the  Army  Enhanced  Position  Location  Reporting 
System/Variable  Message  Format  (VMF)  ground  network  and  the  JDN  so  that  CAS  aircraft  can 
have  a  more  accurate  location  of  friendly  ground  forces  to  reduce  fratricide  and  allow  more 
accurate  air  strikes  in  proximity  to  the  FLOT. 

3. 3. 4.4  Air  Force-Navy  Interoperability  Issues 

The  Navy  and  Air  Force  have  fewer  issues  with  fratricide  and  coordination  of  flying  and  surface 
forces,  but  important  interoperability  matters  nevertheless  require  attention.  In  some  scenarios,  a 
“JFACC  Afloat”  will  run  the  air  war,  at  least  in  its  early  stages,  from  a  Fleet  Command  Ship 
such  as  the  USS  Coronado,  and  assigned  Air  Force  units  must  be  prepared  to  operate  with  such 
an  AOC.  Naval  aviation  must  be  able  to  receive  the  ATO  and  smoothly  feed  tasking  into  its 
mission  planning  systems.  Dynamic  control  of  operations,  retasking  of  aircraft  in  flight, 
coordination  of  strikes  on  time-critical  targets,  and  combat  search  and  rescue  are  just  a  few  of  the 
areas  where  high  levels  of  interoperability  are  critical. 

In  future  coalition  operations,  the  Air  Force  is  likely  to  operate  with  allied  navies.  Examples  of 
potential  allied  contributions,  the  first  three  of  which  could  entail  interoperability  with  Air  Force 
aircraft,  include 

•  Development  of  new  guided  missile  anti-air  warfare  frigates  with  state-of-the-art  3D  radars  and 
longer-range  surface-to-air  missiles  (France,  Germany,  Italy,  Spain,  and  UK) 

•  Development  of  new  amphibious  warfare  ships  (Italy,  Spain,  and  UK) 

•  Ships  for  surface  surveillance  (multiple  nations) 

•  Continued  proficiency  in  the  key  niche  area  of  mine  countermeasures  (France,  Germany, 
Netherlands,  and  Spain) 

The  following  Navy  systems  must  interoperate  with  Air  Force  C4ISR  systems,  tallied  in  rough 
order  of  importance: 

•  Joint  Tactical  Information  Distribution  System  (JTIDS)-VMF.  Air  Force  and  Naval  Air 
cannot  work  together  without  Link- 16.  The  greatest  challenge  is  to  get  the  message  formats  into 
each  airplane  as  needed  to  accomplish  the  mission.  The  Navy  and  the  Air  Force  use  different 
message  formats  to  pass  data  and  information,  often  resulting  in  incompatibility.  Other  data  links 
(Situation  Awareness  Data  Link  [SADL],  Information  Dissemination  Management  [IDM],  etc.) 
may  also  present  issues. 

•  GCCS-Maritime  (GCCS-M).  This  will  be  an  essential  provider  of  data  to  the  COP/FIOP  for  all 
users,  including  the  Air  Force. 

•  Global  Combat  Support  System-M  (sometimes  known  as  the  Navy  Tactical  Command 
Support  System).  Compatibility  is  essential  to  joint  logistics  planning  and  execution. 

•  AEGIS.  This  is  an  essential  participant  in  mutual  support  among  all  services  in  the  littoral 
battlespace  for  both  air-air  and  theater  ballistic  missile  defense  operations. 
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•  Joint  Mission  Planning  System  (JMPS).  This  is  intended  to  be  a  joint  system  that  ensures 
compatible  mission  planning;  there  could  be  issues  if  Service-specific  solutions  are  employed. 

•  JSIPS-N,  including  the  Tactical  Input  Segment.  Compatibility  is  essential  for  joint  support 
with  tactical  imagery. 

•  Cooperative  Engagement  Capability  (CEC).  This  could  become  the  basis  for  the  Joint 
Composite  Tracking  Network  (JCTN),  and  will  be  a  major  element  in  joint  air  defense  operations 
in  the  littoral. 

•  Advanced  Combat  Direction  System.  This  is  being  implemented  on  attack  carriers,  but  is 
currently  not  even  interoperable  with  AEGIS,  let  alone  Air  Force  systems. 

•  Joint  Tactical  Radio  System  (JTRS).  This  and  other  common  tactical  radios  will  be  critical  in 
joint  operations. 

•  TALON  Gateway.  This  Air  Force  Tactical  Exploitation  of  National  Capabilities  Program 
(TENCAP)  initiative  is  to  put  a  “translator”  onto  a  widebody  aircraft  to  send  and  receive 
ultrahigh  frequency  over-the-horizon  information,  translate  it  into  the  proper  format  (Link- 1 6, 
SADL,  and  IDM),  then  retransmit  the  data  or  imagery  to  the  appropriate  fighter  aircraft.  This 
system  could  be  the  model  for  future  efforts  to  “unstovepipe”  systems. 

•  Airborne  Broadcast  Information.  This  effort,  sponsored  by  Air  Mobility  Command  (AMC),  is 
a  direct  descendant  of  the  Multi-Source  Tactical  System  developed  by  Air  Force  TENCAP. 

AMC  is  purchasing  many  of  these  systems  for  its  aircraft  to  give  them  enhanced  situational 
awareness;  interoperability  with  supported  Navy  units  would  be  valuable. 

•  Radiant  Topaz.  This  is  a  Surveillance,  Reconnaissance,  Management  Tool  for  collection 
management. 

•  Multilevel  Security  (MLS).  In  general,  a  robust  joint  solution  to  the  MLS  challenge  is  a  major 
issue. 

•  Meteorology  and  Oceanography  (METOC).  The  Navy  has  a  very  robust  system  here  that 
could  help  meet  the  needs  of  the  other  Services. 

33.4.5  Air  Force-Coalition  Interoperability  Issues 

Economic,  doctrinal,  and  regional  concerns  intervene  to  inhibit  interoperability  between  the 
United  States  and  its  allies.  Many  of  our  partners  in  NATO  and  elsewhere  understand  that  they 
cannot  reach  parity  with  the  United  States  in  levels  of  C4ISR  investment.  Especially  when  the 
United  States  does  not  have  a  robust  and  proven  CONOPS  for  information-enabled  operations  in 
place,  allies  facing  resource  constraints  and  competing  priorities  can  conclude  that 
interoperability  is  not  achievable.  In  addition,  allies  face  difficult  decisions  between  buying  U.S. 
systems  as  a  route  to  interoperability  and  supporting  their  own  or  their  neighbors’  industries; 
issues  of  workshare  and  releasability  of  information  and  technology  are  crucial  in  this  context. 
The  United  States  has  not  always  been  sufficiently  proactive  in  bringing  allies  into  system 
requirements  definition  and  program  planning  to  allow  time  for  mutually  acceptable  acquisition 
decisions  to  be  worked  out. 

We  can  illustrate  trends  in  C4ISR  that  may  contribute  to  interoperability  problems  in  terms  of  the 
conventional  three-level  hierarchy  of  theater  tactical  networks  as  shown  in  Table  3-2. 
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Table  3-2.  Network  Tiers  in  the  U.S.  C4ISR  Structure 


Network  Tier 

Existing/Planned  Systems 

Joint  Planning  Network  (JPN) 

•  Defense  wide-area  networks  (Non-Secure  Internet  Protocol 
Router  Network/Secret  Internet  Protocol  Router  Network 
(SIPRNET),  Joint  Worldwide  Intelligence  Communications 
System,  etc.)  supporting  GCCS,  Joint  Deployable  Intelligence 
Support  System,  Defense  Message  System  (DMS) 

•  Secure  voice  and  data,  Global  Broadcast  System,  video 
teleconferencing  (VTC),  etc. 

•  Planning  networks  (for  example,  TBMCS) 

JDN 

•  Tactical  Data  Links  (Link-11,  Link-16,  etc.) 

•  Theater  and  national  data  broadcasts  (Tactical  Data 

Distribution  System,  Tactical  Information  Broadcast  Service, 
etc.) 

•  Common  high-band  data  link 

JCTN 

•  Sensor  and  weapons  networks 

•  CEC,  sensor-to-shooter  subnets 

The  lowest  tier  of  the  table  has  the  most  timeliness  and  the  most  direct  link  between  information 
and  weapon  employment.  These  networks  connect  information  sources  to  the  combat  direction 
system  of  a  ship,  a  tactical  operations  center,  an  aircraft  mission  computer,  or  a  weapon  guidance 
system.  The  middle  tier  provides  cueing,  situational  awareness,  and  force  coordination.  The 
highest  tier  accommodates  information  exchange,  coordination,  planning,  and  contextual 
information.  In  general,  the  scope  of  network  operations  decreases  and  responsiveness  increases 
in  moving  down  the  tiers.  Using  this  construct,  Table  3-3  highlights  the  present  and  near-term 
prospects  for  coalition  interoperability. 


Table  3-3.  Assessment  of  Coalition  Network  Interoperability9 


Network  Tier 

System 

Interoperability  Assessment 

JPN 

DMS,  TCI/IP-based  messaging 

•  No  blanket  access  to  SIPRNET 

•  Information  exchange  between  networks 
depends  on  coalition  MLS  solution 

GCCS 

•  Allies  buying  subsets;  releasability  of  some 
segments  is  uncertain 

TBMCS 

•  Allies  buying  subsets;  releasability  of  some 
segments  is  uncertain 

Secure  Voice  and  VTC 

•  Issues  with  secure  terminal  equipment, 

Fortezza  encryption  cards,  bandwidth 
limitations,  etc. 

Intelligence  systems 

•  Allies  divided  by  access  to  secure  networks 

JDN 

Data  Links 

Interoperability  and  data  sharing  likely  to  be 
extensive 

JCTN 

Sensor/weapons  networks 

Allied  forces  are  likely  to  be  excluded  by  U.S.  policy 
and  limited  common  system  inventories 

9  R.R.  Odell,  P.  Morley,  K.  Gause,  and  F.  Ruiz-Ramon,  Toward  a  US  Navy’  Strategy’ for  C4 I  Interoperability  with 
Allies,  CAN  Research  Memorandum,  1999. 
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Overall,  there  are  three  reasons  why  problems  with  C4ISR  interoperability  should  be  expected. 
First,  the  U.S.  JPN  will  make  the  most  intensive  use  of  broadband  satellite  communications, 
creating  an  investment  issue  with  our  allies.  Second,  the  proliferation  of  U.S.  and  other  nations’ 
networks  will  compound  the  interoperability  challenge,  especially  in  terms  of  achieving  MLS 
solutions.  Finally,  U.S.  advances  in  IT  are  likely  to  reinforce  a  U.S.  preference  for  employing 
U.S. -only  networks;  access  and  infonnation  releasability  will  continue  to  be  vexing  problems. 

The  limited  ability  of  allies  to  procure  U.S.  systems,  for  both  resource  constraint  and  industrial 
policy  reasons,  will  be  serious  limiting  factors.  Interactions  among  the  three  tiers  of  Tables  3-2 
and  3-3  are  important.  The  increasing  importance  of  information  processes  at  the  JPN  level,  the 
proliferation  of  networks,  the  limited  releasability  of  certain  key  technologies,  the  wide  spread  in 
access  to  satellite  communications  bandwidth,  and  the  limited  availability  of  U.S.  sensor-to- 
shooter  chains  to  allies  will  limit  the  role  their  forces  can  play  in  major  operations.  U.S.  forces 
will  be  in  a  superior  position  with  respect  to  access  to  infonnation  and  often  will  not  know  what 
access  their  allies  have;  allied  access  to  U.S.  networks  is  likely  to  continue  to  be  unsatisfactory. 
Specifically: 

•  In  coalition  operations,  U.S.  armed  forces  are  unlikely  to  change  their  C4ISR  suites  for  the  sake  of 
coalition  interoperability,  increasing  the  importance  of  linkages  to  allied  networks  such  as  the 
NATO  CRONOS  wide-area  network. 

•  Allied  access  to  U.S.  networks  will  be  restricted  and  variable.  Some  nations  will  have  highly 
sensitive  access,  while  others  will  not.  Guards  that  allow  connectivity  between  U.S.  and  allied 
networks  in  an  MLS  environment  will  be  critical. 

•  Restrictions  of  the  U.S.  National  Disclosure  Policy  are  likely  to  be  most  restrictive  at  the  level  of 
the  JPN. 

As  a  result: 

•  Future  coalitions  will  be  stratified  into  groups  of  nations  with  various  degrees  of  C4ISR  capability 
and  interoperability  with  U.S.  systems. 

•  C4ISR  interoperability  is  likely  to  be  poor  for  the  JPN  and  sensor-to-shooter  chains. 

•  The  task  of  diagnosing  C4ISR  interoperability  problems  with  allies  and  setting  requirements  will 
be  scenario-dependent. 

•  U.S.  responsibilities  in  coalition  operations  for  information  operations  and  protection  could 
increase. 

3.3.5  Critical  Processes  for  Interoperability 

Joint  and  coalition  operations,  especially  in  the  emerging  expeditionary  force  model,  demand  a 
level  of  interoperability  that  our  existing  methods  of  acquiring  and  employing  systems  are 
unlikely  to  satisfy.  If  interoperability  is  to  be  achieved,  technical  and  operational  solutions  must 
be  underpinned  by  a  set  of  processes  that  can  actually  deliver  the  desired  result.  Among  the 
most  important  of  these  are  the  processes  governing 

•  Requirements  analysis  and  definition  for  systems,  systems  of  systems,  and  families  of  systems 

•  The  definition,  evolution,  and  application  of  architectures  at  these  same  three  levels,  including  the 
choice  and  enforcement  of  standards 

•  The  acquisition,  testing,  and  long-term  modification  and  upgrading  of  systems 
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•  The  development  and  implementation  of  joint  and  coalition  doctrine,  tactics,  procedures,  training, 
and  exercises  that  make  interoperability  a  routine  and  accepted  fundamental  of  military 
operations 

Unfortunately,  the  processes  that  prevail  in  these  areas  today  are  generally  much  more  of  a 
hindrance  than  a  help.  Process  refonn  will  be  one  of  the  most  important,  but  also  most  difficult 
and  time  consuming,  aspects  of  migrating  our  legacy  forces  and  systems  toward  the  vision  of 
JV2020.  Once  again,  the  Internet  and  commercial  practices  have  much  to  teach  DoD.  We  seek 
an  approach  that  can  drive  critical  processes  toward  the  broad  goal  of  interoperability  while 
balancing  fiscal  and  operational  priorities,  minimizing  the  disruption  of  ongoing  programs,  and 
involving  all  interested  parties,  from  policy  setters  to  system  developers  to  warfighters.  Other 
panel  reports  concentrate  on  operational,  acquisition,  human  factors,  and  technology  processes 
for  C2.  Here,  we  consider  some  aspects  that  are  especially  relevant  to  our  area. 

3. 3. 5.1  The  Problem  Today 

In  working  on  this  study,  we  have  repeatedly  come  up  against  the  problems  that  result  from  a 
platform-centric  view  of  military  systems.  Requirements  definition,  which  is  the  bedrock  to 
which  the  whole  acquisition  process  is  anchored,  remains  fixated  on  individual  systems  to  meet 
specific  operational  needs,  identified  by  narrow  groups  of  users.  There  is  little  or  no 
consideration  of  how  synergy  among  the  diverse  elements  of  an  integrated  force  might  deliver 
more  capability  at  less  cost.  Compounding  the  problem,  DoD  and  the  Services  are  only 
beginning  to  think  about  operational  architectures  and  system-of-systems  frameworks  that  might 
provide  the  kind  of  context  requirements  developers  need  in  order  to  break  out  of  this  mindset. 

In  short,  what  we  have  today  is  mostly  a  recipe  for  non-interoperable  stovepipes.  We  pay  a 
heavy  price  both  in  the  kind  of  operational  problems  described  earlier  and  in  individual  system 
costs  driven  up  by  the  inability  to  use  common  solutions  to  common  needs  and  the  desire  to 
optimize  each  system  instead  of  the  capabilities  of  the  force  to  which  the  system  contributes. 

More  recently,  a  great  deal  of  emphasis  has  been  placed  on  the  infrastructure  dimension; 
examples  include  the  Defense  Information  Infrastructure  Common  Operating  Environment 
(DII  COE)  as  a  way  of  standardizing  information  system  platforms  and  Link- 16  as  the  universal 
tactical  data  link.  In  the  process,  there  has  been  a  tendency  in  DoD  to  apply  standardization 
mandates,  sometimes  before  the  thing  being  mandated  was  mature  enough  for  real-world  use. 
Our  examination  of  the  history  of  TBMCS  suggests  that  a  large  part  of  its  history  of  problems  is 
due  to  the  fact  that  it  was  committed  to  an  early  version  of  DII  COE  that  lacked  both  the 
functionality  and  the  stability  to  support  it.  In  every  case,  the  focus  of  interoperability  initiatives 
has  been  on  the  lower  levels  of  the  hierarchy  in  Figure  3-3,  especially  on  communications 
interoperability,  when,  in  fact,  many  of  the  most  difficult  challenges  lie  at  the  higher  levels. 

3.3. 5.2  Commercial  Practice 

The  practice  in  the  commercial  world  has  rapidly  evolved  from  one  based  on  closed  proprietary 
architectures  with  few  broadly  accepted  standards  to  one  of  open,  agreed-upon  standards  for 
most  layers  of  the  architecture.  In  addition  to  the  technical  lessons  the  private  sector  has  to 
teach,  we  are  interested  in  the  processes  used  to  achieve  these  results.  Some  of  them  are 

•  Individual  companies  see  their  financial  interest  in  value-adding  products  that  exploit  a  common 
infrastructure  rather  than  in  control  of  that  infrastructure.  This  actually  creates  powerful 
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incentives  to  share  information  and  agree  to  compromise  on  definition  of  standards  so  that  the 
foundation  on  which  competitive  advantage  is  then  erected  can  be  put  in  place  quickly. 

•  Standards  activities  are  community  based,  and  arise  from  communities  of  interest  in  specific 
domains  such  as  banking,  product  engineering,  and  music.  While  standards  committees  are 
notoriously  messy,  time  consuming,  and  contentious,  they  have  an  excellent  track  record  in 
hammering  out  workable  compromises  in  time  to  meet  the  needs  of  the  participants. 

•  Standards  are  primarily  oriented  to  interfaces  and  shared  processes,  rather  than  products,  although 
the  dynamics  of  the  marketplace  may  create  de  facto  standards  around  products  like  Microsoft 
Windows.  The  minimum  set  of  standards  that  can  ensure  interoperability,  both  generally  and 
within  a  specific  domain,  is  all  that  will  be  developed.  The  outstanding  example  is  the  Internet 
protocol  stack,  especially  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP),  and  other 
effective  standards  have  been  widely  used  file  formats  (GIF,  JPG,  etc.)  and  popular  application 
programming  interfaces  (APIs). 


The  evolution  of  the  commercial  marketplace  from  competing  proprietary  architectures  (IBM, 
Burroughs,  and  others)  to  open  architectures  with  interface  standards,  as  described  above,  is 
instructive.  Through  the  1970s,  computer  manufacturers  saw  their  financial  interest  in  signing 
customers  up  to  their  proprietary  architecture.  With  the  development  of  the  microcomputer,  and 
the  commercial  development  of  DOS  as  a  proprietary  architecture  with  an  open  API,  the  market 
began  to  shift.  Software  developers  began  to  develop  a  wide  range  of  applications  for  the  open 
API,  and  buyers  wanted  to  be  able  to  exploit  this  software.  Competing  proprietary  architectures, 
even  technically  superior  ones  like  the  Macintosh,  struggled  in  the  marketplace  because  the  users 
demanded  access  to  the  wide  range  of  independently  developed  software.  This  process  of 
standards  extended  to  information  exchange  protocols  such  as  hypertext  markup  language 
(HTML)  and  Structured  Query  Language.  The  process  of  opening  the  architecture  is  continuing; 
if  current  trends  continue,  the  LINUX  system,  which  has  open  source  code  as  well  as  an  open 
API,  will  overtake  Windows  NT  as  the  most  popular  server  system  in  200 1.10  DoD  lacks  the 
discipline  of  the  marketplace  and  must  implement  processes  that  provide  the  standards,  the 
common  services  using  them,  and  the  incentive  to  choose  them  in  specific  systems  over  a  set  of 
slightly  better  optimized  stovepiped  solutions. 


3. 3. 5. 3  The  Current  DoD  Interoperability  Approach 

IERs  have  become  the  fundamental  basis  for  defining  and  assessing  interoperability  in  DoD 
systems.  CJCSI  6212. 01B  defines  a  process  as  summarized  in  Figure  3-5.  The  three  key  events 
are  (1)  certification  that  the  relevant  requirements  document  (Mission  Need  Statement, 
Operational  Requirements  Document,  or  CRD)  adequately  addresses  interoperability; 

(2)  certification  that  the  interoperability  requirements  documented  in  the  C4I  Support  Plan 
(C4ISP)  via  the  IER  matrix  and  set  of  system  descriptions  are  supportable  over  the  GIG;  and 

(3)  certification  that  the  results  of  system  test  and  evaluation  prove  that  interoperability 
requirements  are  satisfied.  Those  IERs  designated  as  “critical,  top  level”  define  an 
interoperability  KPP  that  is  a  mandatory  item  for  a  decision  to  proceed  at  major  acquisition 
milestones.  They  thus  take  on  an  importance  far  beyond  engineering  the  interactions  among 
systems. 


10  Briefing  to  the  Summer  Study  by  Walker  White,  ORACLE  Corporation,  10  July  2000. 
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Figure  3-5.  CJCSI  6212.01B  Establishes  a  Process  for  Assessing  and  Certifying  the  Interoperability  of  a 

Developmental  System 


IERs  represent  a  step  forward  from  traditional  thinking  that  tends  to  focus  on  specific  systems, 
channels,  message  formats,  and  the  like  when  addressing  interoperability.  An  IER  is  an 
information  construct  that  is  independent  of  the  physical  means  by  which  the  information 
exchange  is  accomplished.  IERs  provide  the  interaction  piece  of  an  operational  architecture,  and 
they  establish  a  basis  for  both  system-of-systems  and  individual  system  engineering  to  find  the 
most  cost-effective  way  of  servicing  warfighter  infonnation  needs.  However,  they  still  force  the 
architect  to  deal  with  a  huge  number  of  pairwise  connectivity  problems,  and  for  a  major  weapon 
system  the  IER  matrix  becomes  unwieldy,  involving  as  many  as  several  thousand  individual 
information  exchanges  among  dozens  of  platforms.  As  discussed  in  Section  3.3.8  and  in 
Chapter  8,  we  believe  that  the  JBI  is  a  superior  concept  that  will  gradually  replace  IERs  as  the 
fundamental  definition  of  how  a  system  or  user  interacts  with  the  information  infrastructure. 

Today,  the  most  visible  and  controversial  element  of  the  DoD  standardization  approach  to  C  is 
the  DII  COE,  which  is  a  specific  instantiation  of  the  Joint  Technical  Architecture  and  takes  the 
form  of  a  defined  software  load  that  creates  a  standard  execution  platfonn.  The  DII  COE,  and 
the  issues  associated  with  it,  have  been  addressed  by  a  special  study  team,  and  the  results  are 
described  in  Chapter  8. 
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In  addition  to  these  initiatives  and  those  described  in  Section  3. 3. 4. 2,  OASD/C  I  has  defined  an 
Outcome -Based  Interoperability  Process  that  seeks  to  link  many  aspects  of  requirements 
definition,  system  acquisition,  exercises  and  experiments,  and  system  engineering  tools  to  infuse 
interoperability  into  system  programs.  An  early  prototype  of  a  Joint  C4ISR  Architecture 
Planning/ Analysis  System  is  being  tested.  C4ISPs  are  now  mandatory  for  all  major  system 
acquisition  programs  before  beginning  engineering  and  manufacturing  development;  these 
documents  require  the  development  of  an  IER  matrix  and  the  designation  of  the  critical  or  top- 
level  IERs  that  define  the  Interoperability  KPP.  C4ISPs  have  proved  a  useful  vehicle  for  flushing 
out  interoperability  problems  and  helping  system  designers  think  about  the  informational  context 
in  which  their  products  must  operate.  We  are  encouraged  by  the  level  of  attention  that 
interoperability  is  receiving,  but  there  are  as  yet  few  results  to  show  for  it  in  the  real  world  of 
military  operations.  DoD  has  far  to  go  to  approach  the  success  of  the  commercial  world. 

33.5.4  Migration  to  Improved  Processes 

These  considerations  suggest  a  number  of  measures  to  refonn  existing  processes.  We  discuss 
them  in  the  areas  of  operational  architecture  and  requirements,  technical  architecture  and 
standards,  and  acquisition. 

Improving  Operational  Architecture  and  Requirements  Definition.  This  is  arguably  the 
most  important,  and  certainly  the  most  intractable,  area  to  refonn.  In  study  after  study,  the  SAB 
has  called  for  improvement  to  a  process  that  takes  far  too  long,  overly  constrains  acquisition 
PMs,  reinforces  traditional  stovepipes,  and  lacks  any  ability  to  balance  and  harmonize  the 
various  elements  of  the  force.1 1  The  problem  persists.  The  requirements  bureaucracy  is 
entrenched,  the  budget  stakes  are  high,  and  the  imperative  to  change  for  the  sake  of  achieving  the 
goal  of  Infonnation  Dominance  is  not  yet  widely  understood  or  accepted  in  the  operational 
community.  Nevertheless,  we  feel  compelled  to  state  the  case  one  more  time. 

Since  acquisitions  are  conducted  and  money  is  appropriated  system  by  system,  there  will  always 
be  a  certain  system-centric  character  to  acquisition.  However,  the  requirements  that  drive 
individual  programs  can  and  must  be  cast  in  the  context  of  the  complete  force,  including  joint 
and  coalition  participation.  We  need  a  requirements  process  that  reflects  the  way  we  plan  to 
fight — joint,  netted,  interoperable,  and,  eventually,  infonnation-enabled.  The  C4ISR 
Architecture  Framework  establishes  a  reasonable  process  and  set  of  architecture  products.  Well 
thought-out  operational  architectures,  validated  through  analysis,  experiments,  and  exercises, 
must  have  precedence  over  system  requirements  and  the  resulting  system  architectures.  In 
general,  a  System  Program  Director  should  conduct  the  program  under  requirements  that 
suboptimize  the  single  system  because  it  will  be  an  element  of  an  optimized,  integrated, 
interoperable  force.  For  the  information-centric  CONOPS  to  work,  and  for  future  forces  to  be 
affordable  and  supportable,  all  elements  must  conform  to  an  architecture  that  balances  and 
allocates  functions  across  platforms  and  systems. 

This  raises  the  troublesome  issue  of  who  should  serve  as  the  overall  architect  and  how  much 
power  over  individual  system  requirements  and  Service  priorities  that  individual  should  wield. 

As  mentioned  earlier,  the  Joint  Staff/J-38  is  drafting  an  initial  JOA  and  supporting  set  of  JMAs. 


11  The  November  1998  study  A  Space  Roadmap  for  the  21st  Century’  Aerospace  Force,  SAB  TR  98-01  called  for, 
among  other  things,  creation  of  a  force  structure  architect  able  to,  for  example,  trade  off  performance 
requirements  among  space-based  and  air-breathing  platforms. 
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An  initial  high-level  operational  architecture  for  a  Joint  Task  Force  has  been  defined,  using  the 
C4ISR  Architecture  Framework;  this  provides  a  good  starting  point  that  must  now  be  fleshed  out 
in  greater  detail.  Certainly  there  must  be  joint  control,  and  the  Joint  Requirements  Oversight 
Council  would  seem  to  be  the  logical  holder  of  the  baton.  The  Air  Force  still  needs  its  own  force 
architect,  both  to  represent  Air  Force  interests  in  the  joint  arena  and  to  enforce  the  required 
requirements  trades  across  Air  Force  space,  air,  and  surface  systems.  Both  joint  and  Air  Force 
operational  architectures  should  be  closely  tied  to  the  JV2020  vision,  to  the  maturing  concepts  of 
operations  of  Air  Expeditionary  Forces,  to  exercises  such  as  JEFX,  and  to  system-of-systems 
engineering  environments  such  as  the  emerging  JDEP  and  the  Distributed  C4ISR  Simulation 
Network  called  for  in  Chapter  8. 

Improving  Technical  Architecture  and  Standards  Definition.  From  our  consideration  of  how 
the  commercial  world  succeeds,  the  following  emerge  as  the  overall  characteristics  of  the  process 
we  seek  for  moving  the  current  C  environment  toward  a  commercial  model: 

•  Identify  communities  of  interest  involving  users,  developers  and  supporters  of  C2  systems  and 
make  them  the  primary  drivers  in  the  selection  or,  when  necessitated  by  unique  military 
circumstances,  the  development  of  standards.  Ensure  that  architecture  and  standards  are  oriented 
to  the  needs  of  the  system  development  and  operational  communities.  Ensure,  through  a  process 
of  spiral  development,  experiments,  and  exercises,  that  they  are  fully  mature  before  being 
released  for  operational  use. 

•  Tie  the  definition  and  refreshment  of  this  standards  profile  to  the  spiral  process  so  that  standards 
evolve  with  the  systems  that  use  them.  Focus  the  standards  activity  on  the  adoption  of  the 
minimum  set  of  standards  adequate  to  achieved  the  required  interoperability. 

•  Provide  incentives  for  the  use  of  standards  through  economic  benefits  to  contractors  and 
economic  and  operational  benefits  to  users  rather  than  through  mandates.  Exploit  the  fact  that  a 
good  standards  package  reduces  technical  risk  and  development  cost,  allowing  resources  to  be 
used  to  implement  functionality,  instead  of  repeating  past  experiences  where  standards  mandates 
have  consumed  huge  program  resources  in  the  effort  to  make  them  work. 

•  Make  common  infrastructure  available  such  that  it  can  be  used  when  it  meets  system  needs  and  as 
a  contributor  to  interoperability.  This  will  be  especially  true  for  common  information  services, 
including  data  maintenance,  replication,  access,  and  the  communications  environment. 

•  Develop,  maintain,  and  evolve  common  technical  models  at  all  levels  of  the  interoperability 
hierarchy  and  use  these  as  the  primary  basis  for  interoperability. 

•  Provide  top-level  direction,  vision,  leadership,  and  enforcement  to  ensure  consistent  application 
of  the  interoperability  strategy  across  organizations  and  programs. 

As  discussed  more  fully  in  Section  3.3.7,  commercial  systems  rely  heavily  on  layered 
architectures  to  maintain  compatibility  among  heterogeneous  computing  environments, 
accommodate  growth,  and  cope  with  technology  evolution.  Different  elements  in  such  a  layered 
architecture  tend  to  have  different  growth  paths,  and  DoD  needs  to  find  ways  to  allow  such  non- 
synchronized  evolution  at  various  levels  of  its  infonnation  infrastructure.  For  example,  it’s 
likely  that  the  higher  levels  of  the  hierarchy  in  Figure  3-3,  involving  brain-to-brain 
interoperability  between  one  human-computer  interface  and  another,  will  change  more  rapidly 
than  the  lower  levels,  where  legacy  systems  that  cannot  be  instantly  replaced  will  continue  to 
provide  the  physical  and  messaging  layers. 

Open  architectures  that  allow  individual  layers  to  be  integrated  or  modified  with  minimal  cost 
will  be  essential  for  DoD  to  take  advantage  of  available  commercial  technologies  in  a  timely 

3-25 


manner.  Open  architectures  have  other  advantages,  as  well.  The  less  vertically  integrated  a 
system  is,  the  less  specialized  it  is.  Although  many  physical  layer  implementations  are  very 
unique  to  DoD  systems,  horizontal  integration  increases  the  opportunity  for  integration  of 
commercial  products,  access  to  multiple  vendors  for  the  same  product,  and  multiple  uses  for 
systems  as  a  result  of  flexibility  in  configuration. 

The  basic  message  is  that  the  commercial  world  views  the  business  of  acquiring,  connecting,  and 
using  information  systems  in  a  fundamentally  different  way  from  that  embodied  in  DoD’s 
processes.  Every  path  to  the  information-enabled  force  involves  mastering  and  applying  these 
lessons. 

Improving  Acquisition.  Given  that  the  future  battlespace  will  be  defined  by  an  open,  scaleable 
architecture,  an  evolutionary,  streamlined  acquisition  strategy  will  be  needed  to  enable  rapid 
fielding  of  multiple  future  system  increments.  The  operational  architecture  will  be  crucial  as  the 
foundation  for  establishing  the  constructs  for  information  flow  and  must  be  tied  to  an  acquisition 
strategy  predicated  on  meeting  EAF  requirements.  This  EAF-based  acquisition  strategy  is  a 
significant  detour  from  the  current  system-based  acquisition  strategy;  however,  without  this 
change,  we  will  continue  to  suffer  from  deficiencies  in  interoperability  and  delays  in  achieving 
the  information  systems  needed  to  support  the  EAF.  As  an  example,  acquisition  of  Link- 16 
tenninals  through  the  JTIDS,  MIDS,  and  JTRS  programs  is  primarily  based  on  each  system’s 
individual  capability  to  fund  Link- 16  on  that  platform.  The  timing  of  these  programs  is  not 
based  on  the  needs  of  an  EAF.  As  a  result,  until  every  system  gets  around  to  implementing  Link- 
16  capability  (10+  years  from  now),  we  will  have  multiple  gaps  in  our  key  tactical  data  network. 

Hence  the  basic  reform  in  acquisition  processes  involves  making  interoperability  and  conformity 
to  higher-level  operational  architecture  a  fundamental  element  of  acquisition  strategy.  Many 
individual  steps  are  needed,  from  better  training  of  PMs  and  engineers  in  the  problems  of 
interoperability  and  their  solutions  to  more  realistic  budgeting  and  planning  for  the  effort  needed 
to  achieve  and  demonstrate  interoperability.  Once  more,  the  real  challenge  is  to  break  the 
mindset  that  a  given  program  is  concerned  only  with  its  own  system  and  charged  with  making 
that  system  as  good  as  it  can  be  in  isolation  from  the  rest  of  the  world. 

New  tools  are  available  to  help.  The  rapid  move  to  simulation-based  acquisition,  driven  by  the 
increasing  capability  of  modeling  and  simulation  environments,  makes  it  far  more  feasible  to 
exercise  a  developmental  system  in  a  larger  context  to  support  engineering  trades  and  validate  or 
refine  designs.  The  JDEP  is  a  good  example.  Similarly,  executable  specifications  that  capture 
system  design  in  the  form  of  simulation  objects  can  be  used  as  a  tool  for  ensuring  that  end-to-end 
performance  in  a  system  is  defined  well  enough  to  quantify  and  achieve  a  specific  and  expected 
level  of  military  utility.  Executable  specifications  also  help  with  interoperability  by  ensuring  that 
a  specific  functionality  can  be  reproduced  in  a  different  implementation  or  by  a  different  vendor. 
Tools  that  define  structured  approaches  for  achieving  interoperability  such  as  Through  Life 
Interoperability  Planning  (TULIP,  see  footnote  5)  can  be  and  have  been  used  to  evaluate 
interoperability  and  to  predict  and  correct  problems.  To  be  most  effective,  these  tools  must  be 
applied  throughout  the  entire  life  cycle  so  that  problems  can  be  identified  early,  while  they  are 
relatively  inexpensive  to  fix,  and  so  that  interoperability  can  be  maintained  through  the 
application  of  effective  configuration  management.  TULIP  works  by  adding  rigor  to  existing 
requirements  definition,  testing,  and  configuration  concepts  while  emphasizing  complete  (“brain 
to  brain”)  interoperability  in  a  common  sense  approach. 
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All  of  this  will  increasingly  be  applied  in  spiral  development  programs.  Requirements  and 
designs  will  co-evolve,  and  functionality  will  often  be  delivered  to  the  end  users  in  increments. 
Complex  infonnation  systems  such  as  TBMCS  are  likely  to  continue  to  evolve  over  their 
operational  lifetimes.  The  spiral  methodology  creates  opportunities  to  correct  early  mistakes  and 
to  adapt  to  changing  circumstances.  Interoperability  problems  can  be  tackled  in  manageable 
chunks  corresponding  to  each  performance  increment.  However,  it  remains  true  that 
requirements  must  fully  account  for  interoperability  and  must  be  predicated  on  the  role  the 
system  will  play  in  the  larger  force  context. 

To  conclude  this  part  of  the  discussion,  we  want  to  point  out  that  from  both  interoperability  and 
programmatic  standpoints,  the  Air  Force  must  take  on  the  challenge  of  both  “requiring  and 
acquiring  how  we  fight.”  The  first  “spiral”  of  this  change  is  to  migrate  from  a  system-centric  to 
a  network-centric  capability  wherein  we  have  the  full  compliment  of  necessary  systems 
sufficiently  networked  to  support  EAF  operations.  This  will  require  actions  such  as  providing 
for  centralized  program  elements  (PEs)  that  support  infonnation  systems  (for  example,  a  Link- 16 
PE)  and  then  adjusting  fielding  plans  and  funding  to  support  a  fully  capable  EAF.  This  is  a 
critical  step  in  that  it  is  the  first  major  transition  away  from  the  historical  system-based  planning 
structure.  Once  that  step  is  taken,  the  ground  will  be  prepared  for  migration  to  the  full  JBI. 

3.3.6  Integration  of  Operational  and  Technical  Interoperability 

In  the  preceding  section,  we  stressed  that  technical  and  operational  strategies  for  interoperability 
must  be  supported  by  effective  implementing  processes.  Now  we  turn  to  the  steps  necessary  to 
ensure  that  the  technical  and  operational  dimensions  are  properly  harmonized  and  mutually 
supportive.  As  we  have  stressed  throughout  this  chapter,  interoperability  is  about  providing 
warfighters  with  the  technical  means  to  realize  the  operational  concepts  of  Information 
Dominance.  To  achieve  true  interoperability  we  must  have  a  shared  understanding  of  the 
situation  among  all  the  participants  involved  in  a  particular  activity.  This  understanding  must 
envelop  the  strategic,  operational,  and  tactical  perspectives,  depending  on  the  participant’s 
function  in  the  operation.  Thus  interoperability  transcends  the  technical  perspective  and  requires 
that  operational  doctrine  and  concepts,  procedures,  acquisition  programs,  and  policies  are  tightly 
integrated  within  the  Air  Force,  across  the  Services,  and  with  our  allies. 

33.6.1  First  Steps 

Recent  operational  experience  has  shown  that  the  fluidity  of  the  operational  situation  demands 
enhanced  ability  to  dynamically  respond  to  rapid,  significant  changes.  Technological  advances 
are  exponentially  increasing  our  ability  to  collect  and  share  data.  However,  that  is  insufficient. 
Since  much  of  that  data  is  acquired  in  ways  that  are  not  directly  intertwined  with  our  operational 
and  tactical  environment — always  joint,  often  combined — we  are  not  able  to  effectively 
synthesize  the  data  into  infonnation.  Thus  we  cannot  develop  the  shared  understanding 
necessary  to  take  full  advantage  of  our  current  capabilities.  We  may  one  day  find  that  an 
opponent  who  has  properly  merged  the  technical  and  operational  aspects  of  interoperability  has 
the  advantage  in  combat. 

Since  we  want  to  tie  our  effort  to  bettering  our  operational  capabilities,  and  because  our  national 
security  strategy,  related  policies,  and  doctrine  are  relatively  static,  we  can  begin  there.  The  Air 
Force  has  made  great  strides  over  the  last  few  years  with  its  doctrine  development,  but  much 
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important  work  remains — for  example,  a  publication  that  synthesizes  current  doctrine  and  tells 
the  JFACC  how  aerospace  power  should  be  employed  at  the  operational  level. 

The  translation  of  that  doctrine  into  CONOPS  to  support  the  C  of  theater  operations  is  in  its 
infancy.  We  have  earlier  addressed  the  need  to  reform  our  processes  for  requirements 
formulation  and  system  acquisition.  The  new  requirements  paradigm  must  closely  couple 
technology  with  concepts  for  employing  that  technology  to  enhance  operational  capability.  That 
coupling  must  be  evident  throughout  the  development  and  deployment  cycle.  Therein  lies  the 
motivation  for  a  spiral  process. 


One  possible  construct  for  this  integration  is  suggested  in  Figure  3-6.  In  the  current  paradigm  of 
requirements  and  acquisition,  operational  deficiencies  are  derived  by  analysis  of  missions  and 
forces,  translated  into  system  requirements,  and  implemented  as  a  program.  A  typical  “big 
bang”  acquisition  seeks  to  satisfy  the  full  requirement  at  the  conclusion  of  the  development 
process.  The  right  side  of  the  figure  shows  how  the  spiral  development  process  can  be  mated  to 
the  top-level  derivation  of  CONOPS  from  national  military  strategy.  Then  operational  concepts 
are  used  to  formulate  the  operational  view  of  a  new  system,  and  the  iterations  of  the  spiral  allow 
the  CONOPS,  concept,  and  design  to  be  incrementally  refined  and  implemented.  In  this  way,  the 
operational  dimension  and  the  evolving  technical  solution  can  be  kept  consistent  and  evolved  in 
parallel  to  an  acceptable  functionality  for  delivery  to  the  user. 


Current  Paradigm 


Figure  3-6.  The  Traditional  Linear  “Big  Bang’’  Approach  to  Delivering  Military  Capability  Should  Evolve 
Into  One  Linking  the  Development  Spiral  to  Refinement  of  CONOPS  and  Concepts 


The  work  of  the  AC2ISRC  in  this  area  is  essential  in  the  spiral  paradigm.  For  that  work  to  be 
most  useful,  however,  it  needs  to  be  expanded  to  address  joint  and  coalition  operations.  The 
AC2ISRC  should  team  up  with  representatives  from  the  Army  and  Navy  in  the  very  near  tenn. 
Organizations  such  as  the  Army’s  Training  and  Doctrine  Command  and  Communications  and 
Electronics  Command,  the  Navy’s  Naval  Warfare  Development  Command,  and  the  Marine 
Corps  Warfighting  Laboratory  seem  to  be  key  organizations  to  effect  this  refinement.  This  effort 


3-28 


2 

is  critical  to  shaping  the  development,  deployment  and  operation  of  Air  Force  C  systems  and  to 
effectively  training  the  warriors  who  will  use  them. 

These  operational  concepts  should  be  chosen  to  effectively  cover  the  likely  set  of  future 
operational  environments,  as  opposed  to  an  exhaustive  set.  The  chosen  set  of  operational 
concepts  should  then  drive  the  development  of  an  appropriate  operational  architecture  that  will  in 
turn  support  the  development  of  the  necessary  system  views  to  support  force  structure  and 
system  developments.  These  will  then  provide  a  basis  for  policy  makers,  developers,  and 
operators  to  share  a  common  understanding  of 

•  How  system  capabilities  will  support  the  planning  and  execution  of  operations 

•  New  operational  opportunities  afforded  by  new  technology  and  related  systems 

•  How  to  operationally  test  and  certify  the  sufficiency  of  the  systems 

•  How  to  interact  to  further  enhance  system  functionality  through  development  spirals 

3.3. 6.2  The  Context 

Since  these  products  will  be  tremendously  complex  (and  will  evolve  as  a  function  of  the 
insertion  of  refinements — enabled  by  technology  enhancements  to  operational  concepts),  to  be 
truly  useful  they  will  need  to  be  captured  using  knowledge  management  technology.  This  will 
be  helpful  in  two  ways,  because  in  addition  to  helping  the  developers,  the  knowledge  developed 
during  the  development  of  the  products  will  also  be  important  to  the  people  who  actually  use  the 
systems  that  result  in  planning  at  the  strategic,  operational,  and  tactical  levels,  and  in  executing 
operations. 
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Figure  3-7.  Technology  Will  Increasingly  Allow  Automated  Processes  that  Aggregate  Data  into 
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We  must  now  turn  to  another  dimension  of  the  interoperability  challenge — the  technical 
perspective.  Here  we  begin  to  describe  the  relationship  between  the  decision  space  shared  by 
operational  commanders  and  other  decision  makers,  the  information  and  data  that  they  require, 
and  the  communications  and  networks  foundation  on  which  the  process  stands.  Figure  3-7 
depicts  the  end-to-end  interoperability  construct  for  decision  support.  This  is,  of  course,  merely 
an  expansion  (although  an  important  one)  of  the  layered  interoperability  construct  in  Figure  3-3. 

In  the  long  term  (5  to  15  years)  we  can  anticipate  the  emergence  of  technology  that  will  allow  us 
to  incrementally  automate  the  knowledge  formation  layer.  Even  though  it  is  possible  to  assist 
commanders  and  other  operational  decision  makers  with  computerized  decision  support  systems 
based  on  Bayesian  logic  and  probabilistic  estimates,  shared  understanding  will  be  the  limit  of 
achievable  information  support  for  the  foreseeable  future.  However,  even  this  technology  has 
the  potential  for  tremendous  (perhaps  order-of-magnitude)  reductions  in  decision  cycle  times. 
This  will  be  true  even  though  we  can  anticipate  that  the  available  information  will  grow 
exponentially.  The  Defense  Advanced  Research  Projects  Agency,  the  Service  laboratories,  and 
industry  are  investing  in  these  areas.  We  must  continue  those  investments,  and  AFRL/HE  and 
AFRL/IF  should  take  the  lead  in  sponsoring  and  encouraging  work  on  information  models  (see 
Chapter  8)  to  focus  the  inference  engines  and  other  techniques  being  pursued. 

In  the  mid-term  (3  to  7  years),  automation  of  data  integration  into  information  will  be  enabled  by 
technology  that  is  emerging  today  in  laboratories,  system  centers,  and  industry.  This  technology 
will  significantly  reduce  the  current  72-hour  ATO  battle  cycle  so  that  we  can  more  effectively 
support  dynamic  targeting  as  well  as  the  Army’s  and  Navy’s  24-hour  battle  cycle  targeting 
requirements.  It  will  also  allow  us  to  more  closely  couple  and  enhance  the  effectiveness  of 

information  exchanges  with  our  coalition  partners.  AFRL/IF  and  ESC  should  team  and  add 

2 

emphasis  on  the  Adaptive  Sensor  Fusion  program  and  migrate  the  best  of  breed  into  the  C 
environment  annually.  This  effort  should  be  focused  consistent  with  the  information  model 
described  in  Chapter  8.  The  progression  just  described  is  sketched  in  Figure  3-8. 
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Figure  3-8.  The  Progression,  as  Technology  Advances,  from  Data  to  Understanding 


Once  more  we  note  the  vital  importance  of  shifting  our  focus  from  platform-centric  to  network¬ 
centric,  and  eventually  to  information-centric  operations.  As  communication  networks  have 
become  more  widely  deployed,  the  opportunity  for  enhanced  cooperation  and  coordination 
among  the  C2  elements  is  becoming  real.  Over  the  past  few  years,  the  concept  of  network¬ 
centric  operations  has  become  common.  Applications  are  increasingly  able  to  communicate  and 
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coordinate  by  exchange  of  information  through  common  networks.  Now  the  evolution  of 
communication  and  computing  technologies  has  resulted  in  a  new  opportunity,  that  of 
information-centric  operations.  Concepts  such  as  the  JBI  are  rooted  in  the  idea  of  having  a 
“common  distributed  and  virtual  information  environment”  accessible  by  all  of  the  systems  and 
people  engaged  in  operations. 


Platform-Centric 


Figure  3-9.  The  Evolution  from  Platform-Centric  to  Information-Centric  Operations 


2  •  *2 
Figure  3-9  depicts  the  evolution  of  the  integration  of  C  system  functional  areas  into  a  C 

enterprise.  When  systems  were  developed  as  independent  platforms,  communications  between 

them  was,  at  best,  done  with  dedicated  links.  As  networks  developed,  the  independently 

developed  C  applications  and  modules  were  able  to  exchange  infonnation  through  a  common 

network.  However,  in  both  the  platform-centric  and  the  newer  network-centric  approaches,  the 

systems  and  their  associated  software  applications  generally  “owned”  their  associated  data. 

Information  was  exchanged  between  applications,  rather  than  viewing  the  infonnation  as  the 

common  integrating  aspect. 

The  information-centric  approach  attempts  to  fundamentally  shift  the  paradigm.  Recognizing 
that  interoperability  and  integration  of  C2  functional  areas  into  a  C2  enterprise  requires  the  ability 
to  share  and  mutually  understand  knowledge,  information,  and  data,  the  information-centric 
approach  starts  with  the  premise  of  information  primacy.  The  prime  focus  is  the  information 
architecture  and  model  to  enable  different  command  elements  to  operate  in  a  coordinated 
manner.  This  is  enabled  through  the  common  information  substrate.  Applications,  while 
designed  to  provide  the  commander  and  staff  with  the  ability  to  use  the  information  as  needed, 
are  explicitly  designed  to  operate  on  the  common  information  objects — storing,  processing, 
manipulating,  and  accessing  them  as  needed. 

Interaction  between  C  functional  elements  is  then  implicit.  Since  they  are  operating  on  the  same 
information  objects,  when  an  information  object  is  created  or  modified  by  one  element,  other 
elements  have  immediate  access  to  the  object.  The  information  substrate  provides  the 
mechanisms  (such  as  publish/subscribe)  to  notify  the  C  elements  and  associated  applications 
when  new  or  modified  information  objects  of  interest  are  available. 

3.3. 6.3  Bringing  It  Together 

Finally,  we  are  in  a  position  to  discuss  how  it  should  come  together.  The  technical  perspective 
arises  from  the  application  of  technology  to  produce  shared  understanding  and  the  basis  for 
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collaboration  and  cooperation  among  warfighters.  The  JBI  will  be  the  key  enabler  of  the 
essential  information-centric  thrust  toward  force- wide  interoperability.  Figure  3-10  suggests  the 
way  progressively  higher  levels  of  cognitive  support  to  commanders  and  their  forces  can  be 
thought  of  as  knowledge,  information,  and  networking  environments.  The  operational 
perspective,  then,  arises  from  the  improved  CONOPS  that  are  enabled  by  this  information 
infrastructure  and  evidenced  in  reduced  decision  timelines,  superior  access  to  timely  and  relevant 
information  at  all  echelons,  and  the  ultimate  outcome  of  operational  success  in  the  fonn  of 
mission  accomplishment,  survival  of  friendly  forces,  minimum  collateral  damage,  and  maximum 
efficiency  in  applying  force  to  achieve  military  objectives. 
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Figure  3-1 0.  Technical  and  Operational  Dimensions  of  Information-Centric  Operations  Come  Together  in 
Networking,  Information,  and  Knowledge  Environments  that  Support  Warfighters  at  All  Echelons 
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Figure  3-1 1 .  Demonstrations,  Experiments  and  Exercises  Are  Key  Elements  of  Integrating  Operational 

and  Technical  Solutions  to  Produce  New  Capability 


The  fusion  of  emerging  technologies  and  the  new  CONOPS  they  make  possible  will  often 
involve  three  related  but  distinct  kinds  of  activities  that  progressively  establish  the  feasibility  and 
utility  of  a  new  concept  and  of  the  corresponding  new  system  or  systems.  These  are  technology 
demonstrations,  experiments,  and  exercises,  and  they  are  not  uncommonly  mixed  up.  It’s 
important  to  keep  them  straight,  because  each  plays  a  particular  role.  For  present  purposes,  we 
define  them  as  follows: 

•  Technology  Demonstration:  a  limited  deployment  of  a  new  or  improved  technology,  system, 
architecture,  or  procedure  to  provide  information  and  insight  concerning  the  maturity  and  utility 
of  candidate  approaches  to  enhance  military  capability 

•  Experiment:  a  limited  deployment  of  new  systems,  architectures,  or  procedures  in  a  meaningful 
operational  context  to  evaluate  their  utility,  compare  alternative  concepts,  refine  requirements, 
and  support  operational  and  acquisition  planning 

•  Exercise:  a  limited  deployment  of  new  and  existing  systems,  architectures,  and  procedures  with 
the  involvement  of  operational  personnel  to  validate  their  readiness  for  use  and  support  training 
and  other  preparations  for  early  introduction  of  new  capabilities  into  the  force 

An  exercise  tries  to  emulate  the  real  world  operational  environment  and  place  realistic  stresses 
on  the  concepts  or  equipment  being  exercised.  It  is  intended  to  get  as  close  as  possible  to  real 
operations.  In  some  sense,  exercises  provide  the  military  with  a  substitute  for  a  commercial 
market  as  a  testing  ground  for  alternative  futures.  An  experiment,  by  contrast,  is  aimed  at 
answering  a  set  of  questions  about  new  concepts  and  systems.  If  hoped-for  results  are  not 
achieved,  the  experiment  is  not  a  failure  but  rather  a  source  of  valuable  information  about 
previously  untested  ideas.  Finally,  a  technology  demonstration  provides  a  channel  for 
technology  users  to  interact  with  possible  customers  and  show  the  kinds  of  capabilities  that 
emerging  technology  may  make  possible.  Figure  3-11  is  a  somewhat  idealized  flow  from 
proposed  technology  and  concepts  to  fielded  systems  that  indicate  the  place  of  each  of  these 
events. 
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Improved  interoperability,  and,  in  the  larger  sense,  improved  military  capability  in  general,  result 
from  the  marriage  of  new  operational  concepts  and  the  technical  means  to  realize  them.  The 
vision  of  robust,  flexible,  end-to-end  interoperability,  leading  to  true  “brain  to  brain”  cooperation 
and  shared  understanding,  will  become  reality  in  the  JBI  and  is  the  essence  of  information- 
enabled  warfare. 

3.3.7  Layered  Architectures 

In  this  section,  we  continue  and  expand  the  discussion  of  applying  the  strategies  that  have  proved 
so  successful  in  the  private  sphere  to  attack  interoperability  problems  in  military  C  systems. 
Architecture  is  the  foundation  and  enabler  of  C2  and  is  thus  a  thread  running  throughout  this 
Study.  One  of  the  central  principles  that  underlie  the  success  of  the  Internet  and,  in  general,  the 
approach  of  commercial  systems  to  interoperability,  is  the  use  of  layering  in  the  architectures  of 
networks  and  nodes.  Layered  structures  provide  successive  abstractions  from  implementation 
details  and  establish  broadly  useful  interfaces  to  enable  processes  to  interact. 

In  the  course  of  the  study,  we  have  identified  and  investigated  a  number  of  other  technical  issues 
that  are  closely  related  to  the  JBI.  These  include  infonnation  modeling  and  other  aspects  of 
establishing  a  shared  information  environment.  Chapter  8  of  this  Volume  contains  a  focused 
discussion  of  these  matters  and  a  recommended  path  to  realize  the  infonnation  technology 
foundation  of  the  JBI.  Here,  we  address  the  general  topic  of  layered  architectures  and  their  role 
in  implementing  highly  interoperable  infonnation  systems. 

3.3. 7.1  Commercial  Layered  Architectures 

The  layered  architecture  of  the  Internet  makes  the  ready  interoperability  of  the  World  Wide  Web 
possible.  It  also  provides  a  wide  range  of  benefits  to  the  commercial  world.  For  example,  it 
makes  possible  the  creation  of  Web-based  businesses.  A  properly  layered  architecture  would 
provide  numerous  benefits  to  the  Air  Force,  some  of  which  are  described  below.  The  Air  Force, 
and  DoD  in  general,  should  adopt  a  layered  approach  to  communications  architecture.  It  is 
important  to  understand  how  the  civilian  system  is  structured,  and  how  the  benefits  flow  from 
that,  in  order  to  understand  how  the  Air  Force,  and  DoD  as  a  whole,  should  structure  their 
architecture  and  what  benefits  can  be  expected. 
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Figure  3-12.  Commercial  Layered  Architectures  Point  the  Way  to  Interoperability  in  C2 

The  layering  on  the  commercial  side  is  represented  by  the  left-hand  side  of  Figure  3-12.  The 
first  column  represents  the  layering  of  the  Internet.  The  bottom  layer  contains  the  physical 
connections  over  which  the  data  flows.  It  includes  phone  lines,  microwave  links,  and  fiber.  The 
second  is  the  equipment  and  protocols  to  send  bits  over  the  physical  layer.  The  top  two  layers 
describe  how  data  are  incorporated  in  packets  and  switched  from  computer  to  computer  reliably. 
These  layers  describe  the  Internet,  and  for  the  first  two  decades  of  its  existence,  the  Internet 
functioned  primarily  using  these  layers.  In  those  days,  Internet  users  connected  to  a  remotely 
located  computer,  logged  on,  and  used  the  resident  software.  The  transformation  between  data 
and  information  was  done  on  the  hosting  computer.  Thus,  what  was  supported  was  point-to- 
point  communications.  In  effect,  the  Internet  replaced  the  phone  company  network.  There  was 
also  limited,  low-level  file  transfer,  but  conventions  on  the  format  and  meaning  of  data  were 
settled  on  a  point-to-point  basis.  There  was  no  thought  of  an  “Internet-based  business.”  Because 
the  architecture  was  properly  layered,  the  Internet  survived  several  generations  of  changes  in  the 
physical  layers  and  the  computers  implementing  the  data  links,  and  the  evolution  of  TCP  from 
earlier  transport  protocols.  Each  layer  could  evolve  at  its  own  pace  without  upsetting  the  other 
layers.  Furthermore,  multiple  generations  of  each  layer  could  coexist  and  interoperate.  This  was 
held  together  by  the  relative  stability  of  the  IP  layer,  and  to  a  lesser  extent  the  TCP  layer.  That 
is,  provided  a  user  has  a  computer  interface  board  that  can  send  and  receive  TCP/IP  packets,  the 
user  can  connect  to  the  Internet  with  the  expectation  of  being  able  to  exchange  data  with  other 
computers,  including  those  yet  to  be  designed  and  built. 

The  next  column  shows  the  World  Wide  Web;  this  is  layered  on  top  of  the  Internet.  The  addition 
of  data  transfer  protocols  and  infonnation  models  allows  the  Internet  to  support  the  exchange  of 
information  rather  than  data.  This  means  that  a  user  thinks  of  a  Web  page  putting  information 
“on  the  web”  and  of  using  a  browser  to  pull  information  “off  the  Web.”  Even  though  all  the 
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communication  actually  occurs  point  to  point  in  the  Internet  layers,  it  is  sensible  to  think  of  each 
system  communicating  with  the  Web,  rather  than  with  other  computers  on  the  Web.  There  are 
numerous  benefits  to  this  approach.  One  of  the  most  important  is  that  a  developer  can  design 
and  test  an  application  that  can  interact  with  all  the  needed  computers  by  making  sure  that  it 
interfaces  to  the  Web.  Thus,  a  company  like  Amazon.com  can  develop  and  run  a  Web-based 
application  allowing  customers  to  find,  browse,  and  purchase  books  without  testing  whether  it 
works  on  each  Web  browser,  operating  system,  or  computer  that  a  customer  may  have. 

Likewise,  a  vendor  can  develop  a  computer  or  Web  browser  without  testing  it  against  all  the  sites 
a  customer  may  want  to  visit.  This  in  turn  allows  the  development  of  Web-based  business 
models  and  Web-based  businesses.  The  relative  stability  of  the  data  transfer  protocol  and 
information  models  is  the  key  to  allowing  this  to  work;  anyone  can  design  Web-based 
applications  to  html  and  related  protocols  such  as  Graphic  Interchange  Format  with  confidence 
that  they  will  work  with  all  types  of  computers  and  systems. 

3.3. 7.2  Layered  Architecture  and  the  JBI 

The  right-hand  side  of  Figure  3-12  shows  what  a  layered  architecture  for  the  military  would  look 
like.  The  third  column  of  the  chart  shows  a  connectivity  structure.  The  requirements  for  this 
structure  differ  from  those  for  the  Internet  in  that  it  must  be  secure  against  physical  and 
electronic  attack,  must  support  real-time  communications,  and  must  interact  at  high  bandwidth 
with  highly  mobile  platforms  such  as  combat  aircraft  in  flight.  The  network  layer  of  this  will 
probably  be  based  primarily  but  not  entirely  on  IP,  and  the  physical  layer  will  include  wires, 
fiber,  radio  waves,  satellite  communication  (SATCOM)  channels  and  so  on.  Large  sections  of 
the  physical  layer  will  be  based  on  legacy  systems  (for  example,  SATCOM).  A  crucial 
challenge  will  be  to  organize  these  legacy  systems  to  provide  a  connectivity  layer  with  the 
requisite  robustness,  capacity,  and  flexibility. 

The  JBI  will  be  built  on  top  of  this  Global  Grid  in  the  same  way  that  the  Web  is  built  on  the 
Internet.  If  the  architecture  for  the  JBI  is  correctly  designed,  it  will  provide  two  large  benefits. 
One  is  that  it  will  allow  PMs  to  ensure  that  their  platforms  and  systems  will  be  interoperable  with 
all  other  systems  by  specifying  and  testing  their  interaction  with  the  JBI,  rather  than  individually 
with  each  platform  with  which  they  must  interact.  The  other  is  that  it  will  enable  the 
development  of  JBI-based  C4ISR  applications.  The  availability  of  these  applications  will  permit 
the  development  of  operational  concepts  for  fully  cooperative  forces. 

2 

The  layers  can  evolve  independently  at  their  natural  pace.  This  allows  the  components  of  the  C 
system  to  keep  pace  with  commercial  developments  in  a  manner  consistent  with  acquisition  law 
and  policy  while  remaining  interoperable  with  each  other  and  the  force  elements.  The  major 
interoperability  payoffs  will  come  in  the  way  layered  architecture  facilitates  the  development  and 
evolution  of  the  JBI.  This  is  explored  more  fully  in  the  next  section. 

3.3. 7.3  Interoperability  and  Security 

A  fully  interoperable  force  is  vulnerable  to  information  warfare  attacks  on  its  C4ISR  systems. 
These  can  take  many  forms,  including  physical  attacks  on  its  links,  jamming  of  links,  attempts  to 
insert  false  information  into  RF  links,  the  use  of  captured  equipment  to  insert  false  information, 
and  attacks  by  agents  within  the  system.  The  more  interoperable  the  system,  the  greater  the 
effect  that  bad  data  can  cause.  The  periodic  virus  “epidemics”  on  the  Internet  are  an  example. 
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In  general,  the  Air  Force  does  a  good  job  of  protecting  its  links  from  attack  and  jamming,  and  the 
use  of  encryption  impedes  both  eavesdropping  and  the  insertion  of  false  information  over  links. 
However,  there  are  two  areas  that  merit  attention.  One  is  to  ensure  that  the  Air  Force  C2  system 
degrades  gracefully  when  the  connectivity  bandwidth  is  reduced  by  physical  attack  or  jamming. 
The  Army  Enterprise  Architecture  provides  a  good  example  of  this.  The  other  area  is  to  make 
sure  that  the  layered  architecture  contains  adequate  security  provisions  to  limit  the  spread  of  bad 
information  inserted  using  equipment  captured  by  inside  agents  and  to  remove  it  as  efficiently  as 
possible. 

3.3.8  Interoperability  and  the  JBI 

Over  the  past  3  years,  the  SAB  has  developed  and  refined  the  JBI  as  the  recommended  goal 
toward  which  all  C4ISR  systems  should  migrate.12  The  power  of  the  JBI  concept  is  especially 
notable  in  the  area  of  interoperability.  This  can  be  seen  most  clearly  by  comparing  the  current 
situation,  where  interoperability  is  defined  and  worked  through  the  IER  matrix,  with  what  will  be 
the  case  once  the  JBI  is  implemented. 

The  idea  of  the  IER  represents  a  major  advance  over  earlier  ways  of  looking  at  interoperability. 

It  substitutes  an  information  construct  for  the  older  view  based  on  specific  channels,  links, 
tenninals,  and  message  sets.  An  IER  can  be  mechanized  through  any  link  or  channel  that 
satisfies  its  timing,  data  exchange,  and  security  requirements.  It  is  thus  a  great  step  toward 
openness  and  an  infonnation  interface  approach.  However,  the  sheer  number  of  IERs  and  of 
platforms  and  systems  among  which  they  must  be  defined  makes  this  still  a  very  awkward  and 
inefficient  way  to  specify,  implement,  test,  and  certify  interoperability.  Any  given  C4ISR  or 
weapon  system  is  likely  to  interact  with  dozens  of  other  systems  and  to  require  thousands  of 
IERs,  as  recently  prepared  C4ISPs  illustrate.  Each  pairwise  relationship  among  platforms  creates 
an  interface  that  must,  in  principle,  be  verified.  The  C4ISP  prepared  for  the  Joint  Strike  Fighter 
(JSF)  documents  several  thousand  IERs,  some  of  which  specify  50  or  more  other  platforms  and 
systems  with  which  the  JSF  must  exchange  information.  Those  IERs  that  are  critical — about  70 
in  the  case  of  JSF — involving  dozens  of  platforms,  must  be  tested  by  JITC  before  the  JSF  can  be 
approved  for  production.  This  effort  can  only  ensure  that  the  JSF  is  interoperable  with  those 
platforms  known  to  the  writers  of  the  C4ISP.  Since  the  JSF,  if  successful,  will  be  operated  by  the 
Air  Force  and  other  Services  for  many  years  after  the  C4ISP  is  written,  the  initial  set  of  platforms 
is  likely  to  be  only  a  fraction  of  those  with  which  the  JSF  must  interact  over  its  service  life. 

Thus,  despite  the  large  effort  to  compile  the  IERs  and  then  to  develop  and  test  them, 
interoperability  of  the  JSF  will  periodically  be  a  problem  for  the  Air  Force  as  new  platfonns 
come  on  line. 


12  SAB  report,  Infonnation  Management  to  Support  the  Warrior,  SAB-TR-98-02,  December  1998;  SAB  report. 
Building  the  Joint  Battlespace  InfoSphere,  SAB-TR-99-02,  December  1999. 
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Figure  3-13.  The  JBI  Greatly  Simplifies  the  Specification  and  Assessment  of  Interoperability 


This  contrasts  sharply  with  the  situation  in  a  world  with  a  layered  JBI  architecture.  The 
interoperability  requirements  are  now  to  provide  a  set  of  data  links  and  other  channels  to  ensure 
connectivity  to  the  JBI,  and  to  ensure  correct  transmission,  reception,  and  processing  of 
information  according  to  the  JBI  information  model.  While  this  last  requirement  will  be  more 
complex  than  any  single  current  IER,  it  will  be  far  less  complex  to  deal  with  than  a  collection  of 
thousands  of  them.  Interoperability  testing  is  simplified  because  it  can  now  be  done  with  a 
single  JBI  instantiation  rather  than  with  a  multiplicity  of  platforms.  Furthermore,  future 
interoperability  with  new  systems  is  assured,  provided  they  similarly  conform  to  the  JBI 
interface.  Figure  3-13  highlights  the  difference. 

With  the  JBI,  the  same  physical  events  may  occur  in  executing  an  information  exchange  as  with 
today’s  platform-to-platform  view,  but  the  logical  process  is  completely  different.  In  the  JBI,  the 
plethora  of  IER  interfaces  reduces  to  a  single,  albeit  very  complex,  interface  between  a  platform 
and  the  InfoSphere.  Interactions  with  the  external  environment  via  the  JBI  are  accomplished 
through  publish-and-subscribe  mechanisms  that  are  far  simpler  to  deal  with  than  hundreds  or 
thousands  of  specific  information  exchanges.  The  responsibility  for  the  rest  of  the  process,  from 
connectivity  among  platforms  to  consistent  treatment  of  information,  is  transferred  to  the  JBI. 

The  transfonnation  layer  (implemented  with  “fuselets”)  around  the  central  object  repository 
facilitates  the  definition  and  implementation  of  this  interface  to  a  legacy  or  future  system.  Now 
the  KPP  becomes  implementation  of  the  single  JBI  interface.  This,  in  combination  with 
enhanced  access  to  diverse  infonnation  services,  makes  the  JBI  the  fundamental  solution  to  the 
technical  aspects  of  interoperability. 
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3.4  Recommendations 

7 

The  emphasis  of  this  study  has  been  on  near-tenn  actions  to  significantly  improve  Air  Force  C 
in  the  next  5  years.  In  the  area  of  interoperability,  most  of  the  recommended  actions  will  begin 
to  pay  off  in  this  timeframe,  but  also  will  entail  fundamental  changes  in  processes,  systems, 
facilities,  and  other  things  that  will  take  longer  to  complete.  We  have  spent  many  years  getting 
ourselves  into  an  interoperability  quagmire,  and  it  will  take  a  while  to  get  ourselves  out.  A 
number  of  interoperability-related  recommendations  are  contained  in  Volume  1  of  this  Study 
report.  The  panel  recommends  the  following  additional  actions,  grouped  by  major  areas  of 
interoperability  problems. 

3.4.1  Near-Term  Interoperability  Corrective  Actions 

3. 4. 1. 1  Specific  Interoperability  Problem  Fixes 

Task  AC2ISRC,  working  with  related  organizations  such  as  the  Commanders  in  Chief 
Interoperability  Program  Offices  and  the  Joint  C4ISR  Battle  Center,  to  identify  specific 
interoperability  problems  such  as  those  cited  in  Section  8.3.2.  The  list  should  be  prioritized  such 
that  problems  correctable  by  simple  technical  changes,  corrections  to  TTPs,  or  other  inexpensive 
measures  are  flagged  and  given  emphasis  for  quick  attention.  Task  AC2ISRC  to  collect  and 
analyze  interoperability  problem  reports  and  task  all  field  organizations  to  report  such  problems 
to  the  Center. 

3. 4.1. 2  Coalition  Interoperability  Focal  Point 

Establish  an  Air  Force  focal  point  to  coordinate  policy,  strategy,  and  actions  involving  C4ISR 
interoperability  with  allies.  Specific  actions  include: 

•  Define  a  process  for  addressing  coalition  interoperability  problems,  including  linkage  to  the  Air 
Force  POM  and  budget  development  process,  to  ensure  that  proper  priority  is  placed  on  them. 

•  Explicitly  address  allied  roles  in  warfighting  plans,  including  capabilities  that  complement  U.S. 
forces  and  guidance  for  allied  C41SR  investments.  Establish  warfighting  contexts  that  clarify 
national  roles  and  policies  and  whether  interactions  will  be  based  on  alliances,  ad  hoc  coalitions, 
or  bilateral  agreements. 

•  Coordinate  allied  participation  in  exercises  and  experiments,  including  definition  of  exercise  and 
wargame  content  that  provides  a  sound  basis  for  exploring  coalition  interoperability  issues  and 
operational  roles. 

•  Maintaining  continuity  in  U.S.  positions  and  representation  in  solution  of  protracted  issues. 

•  Coordinate  foreign  military  sales  activities  that  bear  on  coalition  interoperability. 

3.4.2  A  Framework  for  Interoperability 

3. 4. 2.1  Centralized  Coordination  of  Interoperability  Requirements  and  Activities. 

As  part  of  the  overall  centralized  coordination  and  control  of  C  ,  establish  a  process  and  appoint 
an  Office  of  Primary  Responsibility  to  oversee  the  development  of  interoperability  requirements 
and  to  direct  appropriate  actions  to  resolve  interoperability  shortfalls.  Specific  actions  include 

•  Vigorously  support  the  development  of  Operational  Architectures  (OAs)  and  apply  the  DoD 
C41SR  Architecture  Framework  as  an  intrinsic  element  of  requirements  definition  and  validation. 
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•  Move  to  an  architecture-driven  requirements  model  and  process.  Insist  that  emerging  OAs 
provide  implementable  guidance  for  developing  individual  system  interoperability  requirements 
and  that  compliance  with  these  be  made  a  fundamental  condition  for  programs  to  proceed. 

•  As  the  JBI  matures,  migrate  the  focus  of  C41SP  development  from  “Networthiness  Certification” 
to  “JBI  Certification.” 

•  Challenge  and  oppose  platform-centric  thinking  and  decisions  that  inhibit  interoperability. 
Require,  as  part  of  system  requirements  analysis  and  validation,  that  individual  system 
requirements  be  justified  in  the  context  of  the  overall  force  of  which  the  system  will  be  an 
element. 

•  Establish  a  focal  point  for  modeling,  simulation,  and  analysis  (MS&A)  to  ensure  that  tools  and 
databases  used  to  work  interoperability  are  developed,  maintained,  and  made  available  and  to 
oversee  validation  and  verification. 

•  Coordinate  emerging  C2  architectures,  especially  for  the  JBI,  with  other  Services  and  with  allies. 

•  Coordinate  architectures,  system  requirements,  procedures,  and  other  aspects  of  interoperability 
with  other  Government  entities  (Department  of  State,  the  Federal  Emergency  Management 
Agency,  etc.)  and  with  NGOs  with  which  the  Air  Force  works  during  natural  disaster  responses, 
humanitarian  operations,  etc. 

•  Coordinate  the  planning,  objectives,  participants,  and  products  of  exercises,  experiments  and 
demonstrations  to  obtain  maximum  data  and  insight  for  the  continued  refinement  of  architectures, 
system  requirements,  and  interoperable  TTPs. 

3.4. 2.2  DoD-Wide  Information  Services  Process  and  Information  Repository 

Work  with  DISA  and  the  other  Services  to  establish  an  Infonnation  Services  process  as  part  of 
both  near-term  actions  and  migration  to  the  JBI.  Specific  actions  include 

•  Define  and  validate  a  taxonomy  of  joint  and  coalition  warfighter  information  needs;  exploit 
C4ISPs,  existing  data  models,  and  other  sources;  implement  Service,  joint  and  coalition  doctrine; 
and  establish  a  process  to  refine  the  taxonomy  over  time. 

•  Define  the  characteristics  of  the  JBI  information  repository  (object  schema)  as  requirements  for 
the  information  model  and  define  a  process  to  migrate  current  models  to  the  JBI  objective; 
characteristics  include  metadata  standards  and  repositories,  metadata  definitions  for  model 
elements,  segmentation  and  hierarchy,  transformation  and  traversal  engines,  methods  for 
incorporation  of  legacy  and  local  data  bases  (wrappers,  translators,  etc.),  and  abstraction 
mechanisms. 

•  Direct  Air  Force  Space  Command  to  participate  in  JBI  development  and  to  examine  the  emerging 
JBI  architecture  for  implications  for  network  defense  and  other  aspects  of  information  operations. 

•  Establish  a  process  to  select,  develop  (where  necessary)  and  refresh  standards  for  metadata, 
publish/subscribe,  and  other  attributes  of  the  JBI  infonnation  repository  and  services. 

•  Coordinate  with  individual  programs  (GCCS,  GCCS-AF,  TBMCS,  the  Deliberate  Contingency 
Action  Planning  and  Execution  System,  JMPS,  etc.)  to  migrate  their  information  models  and  data 
repositories  to  the  JBI.  Specifically,  direct  actions  and  provide  funding  to  web-enable  and 
Extensible  Markup  Language-enable  legacy  and  developmental  C2  systems. 

•  Define  and  fund  development  of  needed  common  infrastructure. 

3. 4. 2. 3  Architecture  and  Standards  for  Interoperability 

Take  specific  steps  to  define  and  implement  the  architectural  foundation  of  an  Intemet-like  JBI, 
including 
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•  Direct  Air  Force  Materiel  Command  (AFMC),  through  ESC,  to  require  layered  architectures  for 
C41SR  systems,  especially  the  JBI.  Facilitate  communities  of  interest,  in  the  Air  Force,  with  the 
other  Services,  with  allied  nations,  and  with  the  private  sector,  with  support  funding  as 
appropriate,  to  define  standards,  architecture,  and  common  infrastructure  and  to  articulate  their 
proper  application  and  benefits.  Use  these  communities  of  interest  as  the  vehicle  for  selecting 
and  evolving  a  minimum  required  set  of  standards  to  define  each  layer. 

•  Make  the  incremental  development  and  refinement  of  the  JBI  information  model  a  core  element 
of  the  Air  Force  C2  program  as  a  whole  and  of  the  spiral  JBI  development  in  particular  (See 
Chapter  8  for  additional  details). 

•  Direct  AFMC,  through  ESC  and  AFRL/IF,  to  emphasize  the  Adaptive  Sensor  Fusion  program 
and  migrate  the  relevant  results  into  the  C2  environment  annually.  This  should  be  linked  to  the 
evolution  of  the  JBI  information  model,  which  includes  processes  for  data  aggregation  and 
fusion. 

3. 4. 2. 4  Facilities  and  Procedures  to  Evolve  an  Interoperable  Force 

Create  a  Distributed  C4ISR  Simulation  Network  environment  and  accompanying  procedures  for 
hosting,  evaluating,  developing,  and  exercising  interoperable  C4ISR  systems.  Specific  steps 
include: 

•  Establish  a  network  linking  primary  C  ISR  sites,  such  as  the  experimental  C  facilities  at  Langley 
and  Nellis  AFBs,  the  CUBE  at  Hanscom  AFB,  the  C2TIG  at  Hurlburt  AFB,  the  TACCSF  at 
Kirtland  AFB,  and  possibly  others.  Establish  procedures  and  provide  funding  to  use  this  network 
to  refine  TBMCS,  support  Distributed  Mission  Training,  participate  in  exercises  and  wargames, 
and  in  other  ways  support  the  fastest  possible  transition  to  information-centric  operations  for  the 
EAF. 

•  Participate  in  the  JDEP,  including  appropriate  linking  of  the  Air  Force  C4ISR  network  just 
described  with  similar  networks  of  the  Army  and  Navy. 

•  Direct  ACC,  the  AC2ISRC,  ESC,  Air  Force  Operational  Test  and  Evaluation  Center,  AFRL,  the 
TBMCS  program,  and  other  key  players  in  joint  and  coalition  interoperability  to  vigorously 
pursue  contacts  with  appropriate  Army,  Navy,  and  allied  organizations  and  activities  to  promote 
interoperable  architectures  and  systems  and  compatible  TTP.  Include  the  specific  problems  and 
issues  documented  in  Section  8.3.4,  such  as  the  disconnect  between  the  current  ATO  timeline  and 
Army  needs  for  short-notice  target  notifications  to  attack  helicopters. 

•  As  part  of  the  workup  to  a  deployment  vulnerability  window,  require  the  participating  units, 
including  the  AOC  staff,  to  undergo  interoperability  training  and  pass  an  evaluation.  The  C4ISR 
network  or  JDEP  could  be  used  in  a  distributed  training  mode  to  support  this. 

3.4.3  Interoperability  in  Acquisition  and  Testing 
3. 4.3.1  Interoperability  Across  the  Acquisition  Process 

Ensure  interoperability  is  embedded  in  all  phases  of  system  acquisition.  Specific  actions  include 

•  Define  and  enforce  appropriate  interoperability  content  in  the  documentation  for  every 
acquisition  milestone. 

•  Explicitly  account  for  interoperability  in  program  and  contractual  documents  (  Single  Acquisition 
Management  Plan,  Statement  of  Objectives,  Test  and  Evaluation  Master  Plan,  etc.).  Develop 
explicit  interoperability  content  at  all  levels  of  the  hierarchy  defined  in  Figure  3-3  in  the 
definition  of  outcomes  of  individual  spirals. 
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•  Work  with  JITC,  Joint  Staff  J-6,  and  others  as  appropriate  to  develop  and  refine  interoperability 
testing  and  evaluation  methods,  including  live  testing,  system  integration  laboratory  tests,  and 
MS&A. 

•  Exploit  proven  tools  and  methodologies  by  facilitating  their  incorporation  into  system 
engineering  environments  and  by  requiring  contractors  to  define  and  employ  mature 
methodologies  for  dealing  with  interoperability;  make  this  capability  a  source  selection  criterion. 

•  Where  appropriate,  require  interoperability  assessment  of  developmental  systems  using  the 
environment  described  in  Section  8.4. 1.4,  as  a  central  element  of  simulation-based  acquisition. 

3. 4. 3. 2  Interoperability  Working  Groups 

Direct  the  establishment  of  appropriate  Interoperability  Working  Groups  for  acquisition 
programs  to  provide  the  forum  in  which  common  issues  beyond  the  control  of  individual 
programs  can  be  surfaced,  defined,  and  resolved. 

3. 4. 3. 3  Development  of  TBMCS  and  JBI 

Take  actions  to  achieve  the  fastest  possible  fielding  of  required  C2  capabilities,  with  TBMCS  as 
the  near-term  focus  and  JBI  as  the  overall  strategy.  Specific  actions  include 

•  Host  TBMCS  on  the  distributed  environment  described  in  Section  8.4.2. 4  and  evolve  it  to  achieve 
the  required  C2  functionality  for  the  EAF. 

•  Accelerate  the  development  of  the  JBI,  including  the  key  actions  described  in  earlier 
recommendations  and  using  the  distributed  environment  and  results  of  demonstrations, 
experiments  and  exercises. 

•  To  focus  JBI  development,  select  an  important  immediate  problem  and  make  it  the  basis  for 
initial  JBI  functionality.  We  suggest  that  this  problem  be  the  targeting  of  a  time-critical  target 
such  as  a  pop-up  surface-to-air  missile  system.  The  corresponding  JBI  prototype  should  include 
both  national  and  theater  sensors  such  as  Rivet  Joint,  U-2,  and  Global  Hawk,  with  reachback  to 
national  intelligence  sources,  a  Battle  Command  Center,  and  strike  aircraft.  If  this  is  begun 
promptly,  a  demonstration  as  part  of  JEFX  0 1  is  possible. 

3.5  Conclusion 

There  are  many  reasons  that  the  “fog  of  war”  can  dominate  the  battlespace.  The  right 
information,  delivered  in  a  timely,  consistent,  and  efficient  manner,  may  often  succeed  in 
clearing  the  fog.  Three  situations  need  to  be  considered;  First,  given  that  the  ISR  needs  are  met, 
and  unambiguously  transmitted  to  the  right  action  address,  efficient  and  standardized 
interoperability  may  carry  the  day.  Second,  if  the  ISR  needs  are  not  met,  interoperability  may 
very  well  be  a  secondary  issue,  as  the  lack  of  information  may  result  in  no  action.  In  this  case,  a 
defensive  posture  may  still  allow  order  to  prevail,  so  that  operating  forces  can  live  to  fight 
another  day.  In  the  third  case,  the  most  destructive  result  could  occur  when  the  wrong 
information  is  passed,  or  sent  to  the  wrong  people.  This  could  mean  disaster  to  an  otherwise 
dominant  force.  Lack  of  adequate  interoperability  may  cause  conflicts  or  fratricide  in  strike 
execution,  late  delivery  of  essential  information,  and  asynchronous  or  faulty  command  action.  To 
avert  such  a  situation,  unambiguous,  efficient  interoperability  must  occur.  This  is  a  complex 
problem,  for  which  a  solution  is  absolutely  essential  to  the  effective  prosecution  of  warfare. 
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Appendix  3A 

Interoperability  Panel  Charter 


The  Interoperability  Panel  (IOP)  will  examine  both  the  underlying  technical  issues  and  the 
operational/procedural  issues  associated  with  achieving  robust  interoperability  among  the 
elements  of  an  aerospace  force.  The  objective  of  the  Panel’s  inquiry  is  to  understand  the  factors 
which  enhance  or  impede  interaction  among  force  elements,  to  identify  actions  (including 
organizational  and  procedural  changes)  which  promote  robust  interoperability,  and  to 
recommend  technology  and  system  developments  which  will  improve  the  capability  of  the 
Air  Force  C  infrastructure  to  respond  to  the  full  spectrum  of  operations  likely  to  be  required  of 
aerospace  forces  in  the  21st  century.  Those  missions  range  from  humanitarian  relief  and  low 
intensity  conflict  to  major  theater  warfare  and  cover  the  full  spectrum  of  operational  elements. 
The  panel  will  exploit  relevant  results  from  recent  SAB  studies,  including  those  dealing  with 
Aerospace  Expeditionary  Forces  and  Information  Management  to  Support  the  Warrior,  and  will 
coordinate  closely  with  other  panels,  especially  those  on  Technology  and  Concepts  and  System 
Definition,  on  areas  of  mutual  interest;  focal  points  will  be  established  with  other  panels  as 
appropriate. 

The  prevailing  ideas  about  jointness  and  interoperability  within  the  DoD  and  the  Services  are,  at 
best,  inadequate,  and,  at  worst,  wrong  and  counterproductive.  It  is  generally  believed  that 
“standards-based  design”  is  sufficient  to  achieve  interoperability.  This  is  demonstrably 
nonsense.  In  general,  the  seductive  appeal  of  simplistic  standardization  mandates  seriously 
impedes  strategies  that  can  actually  achieve  interoperability.  Effective  means  of  coping  with 
rapid  technology  evolution,  especially  in  the  commercial  marketplace,  so  as  to  maintain 
compatibility  among  defense  equipments  based  on  different  technology  generations  are  almost 
entirely  lacking.  Bureaucracies  with  entrenched  interests  are  limited  in  their  insight  into  the  real 
issues  and  reluctant  to  change.  The  problems  with  interoperability  within  U.S.  defense  and 
international  agencies  are  compounded  in  the  arena  of  coalition  operations. 

Among  the  specific  issues  the  panel  will  address  are  the  following: 

•  Define  the  information  processes  which  undeipin  information  superiority  in  the  battlespace  and 
the  associated  technical  issues  such  as 

-  A  common  information  model  for  warfighter  interactions 

-  Efficient  mechanization  of  data,  information  and  knowledge  repositories  and  approaches  for 
sharing  their  content 

-  Effective  development  and  maintenance  of  information  intensive  systems 

•  Examine  the  IER  construct  as  defined  in  recent  Joint  Staff  publications,  as  well  as  associated 
policy  and  directives,  as  a  basis  for  achieving  robust,  all-condition  interoperability 

•  Define  the  levels  of  interoperability,  including  connectivity,  communication,  and  compatible 
( “brain- to-brain”)  information  and  knowledge  processes 

•  Identify  and  evaluate  technical  issues  associated  with  terminals,  information  environments, 
networks,  waveforms,  standards,  and  procedures  and  changes  that  can  improve  interoperability. 
For  example,  how  far  will  compatibility  with  the  JTRS  specification  go  in  achieving 
interoperability  among  communications  nodes? 
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•  How  should  the  current  DoD  C41SR  Architecture  Framework  and  supporting  documents  such  as 
the  Joint  Technical  Architecture  be  evolved  to  facilitate  true,  operationally  meaningful 
interoperability? 

In  keeping  with  the  overall  study  Terms  of  Reference,  the  IOP  will  address  both  near  term 
(present  to  2005)  and  farther  term  recommendations  to  the  Air  Force  leadership.  Among  the 
areas  where  immediate  action  to  promote  a  more  connected  and  interoperable  Air  Force  are 

•  Leverage  recent  and  ongoing  efforts  in  multiple  programs  to  define  IERs  and  document 
interoperability  requirements  in  C4lSPs 

•  Build  interoperability  content  into  exercises,  experiments,  wargames,  etc.,  to  refine  and  validate 
IERs,  diagnose  and  correct  interoperability  problems,  and  improve  overall  requirements  in  areas 
such  as  communications  capacity 

•  Implement  the  recommendation  of  the  1998  SAB  Space  Roadmap  Study  to  establish  a  force 
structure  architect  with  control  over  system  requirements;  interoperability  would  be  a  key  aspect 
of  this  function 

•  Start  the  development  of  a  Common  Architecture  Data  Model  as  called  for,  but  not  implemented, 
in  the  DoD  C4I  Architecture  Framework;  make  open,  information-based  architecture  a 
fundamental  requirement  of  the  requirements  and  development  processes  for  all  systems 

In  short,  the  Interoperability  Panel  faces  a  major  challenge  in  articulating  the  true  problems  that 
interfere  with  interoperability  and  in  formulating  actionable  recommendations  which  will, 
inevitably,  involve  unpalatable  organizational,  cultural  and  programmatic  changes.  However, 
the  future  of  U.S.  military  success  depends  critically  on  infonnation  superiority,  and  recent 
experiences  in  Kosovo  and  elsewhere  have  shown  decisively  the  shortfalls  in  existing  processes 
and  programs.  The  Interoperability  Panel  will  seek  to  define  policy,  organizational,  technology, 
system,  and  operational  actions  that  can  rapidly  close  existing  interoperability  gaps  and  lay  a 
solid  foundation  for  infonnation-enabled  warfare  in  the  years  and  decades  ahead. 
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Appendix  3B 

Interoperability  Panel  Membership 


Dr.  John  M.  Borky,  Chair 

Chief  Scientist 

Tamarac  Technologies,  LLC 

RADM  John  R.  Batzler,  USN  (Ret) 

Senior  Warfighting  Analyst 
Center  for  Naval  Analyses 

Prof.  Claude  R.  Canizares 
Director,  Center  for  Space  Research 
Massachusetts  Institute  of  Technology 

Mr.  Steve  Cox 

Lead  Communications  Engineer 
MITRE 

Dr.  Gary  A.  Federici 

Director,  Information  Operations  and  Warfare 
Center  for  Naval  Analyses 

Mr.  Thurman  (Rich)  Haas 

Principal  Director,  National  Systems  Engineering  and  Architecture  Directorate 
The  Aerospace  Corporation 

Lt  Gen  John  B.  Hall,  Jr.,  USAF  (Ret) 
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Dr.  Barry  M.  Leiner 
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Chief,  Airborne  Communications 
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Col  John  J.  Murphy,  Jr.,  USAF  (Ret) 
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Dr.  Michael  P.  Shatz 
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M.I.T.  Lincoln  Laboratory 

Executive  Officer:  Capt  Cristina  Huerta,  AFRL/VASM 
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Chapter  4 

Report  of  the  Technologies  Panel 
Technology  Investment  for  Future  Capabilities 


4.1  Introduction 

The  current  generation  of  Air  Force  command  and  control  (C  )  systems  is  built  on  a  base  of 
commercial  technology,  customized  for  military  functionality.  For  example,  the  Theater  Battle 
Management  Core  System  (TBMCS)  uses  a  commercial  database  (Oracle)  as  its  core  with 
special-purpose  military  applications  riding  on  this  core.  Because  of  the  significant  technology 
development  investment  being  made  each  year  by  the  commercial  software  industry  (over 
$  1  billion  by  Oracle  alone),  commercial  advances  in  information  systems  are  growing  at  an 
accelerated  rate.  This  situation  will  enable  the  Air  Force  to  rapidly  field  new  military 
information  system  capabilities,  such  as  the  Joint  Battlespace  InfoSphere  (JBI),  but  will  also 
place  significant  challenges  on  technology  deployment  within  the  Air  Force’s  C2  structure, 
simply  because  of  the  rate  of  change  of  technology.  As  an  example,  Oracle’s  internal  cycle  time 
from  product  development  to  product  introduction  is  normally  within  a  12-month  window.  The 
Department  of  Defense  (DoD)  acquisition  process  constrains  military  C2  systems  to  a 
significantly  longer  development  cycle,  resulting  in  the  deployment  of  systems  that  are  often 
built  on  already  obsolete  core  products.  For  example,  the  current  release  of  TBMCS  uses  a 
version  of  the  Oracle  database  management  system  that  is  over  a  100  minor  revisions  behind  the 
current  commercial  release. 

Due  to  the  large-scale  investment  in  infonnation  systems  technology  by  commercial  vendors, 
technology,  for  the  most  part,  is  not  a  barrier  to  development  of  Air  Force  C  systems.  In  this 
chapter  an  assessment  has  been  made  of  the  available  technologies  relevant  to  the  C2  intelligence, 
surveillance,  and  reconnaissance  (C2ISR)  mission. 

Perhaps  the  major  challenge  the  Air  Force  faces  is  how  to  leverage  the  infonnation  system 
revolution,  fueled  by  e-commerce,  and  transition  new  capabilities  into  Air  Force  operations  on  a 
fast  time-line.  For  the  first  time  since  World  War  II,  the  Air  Force  lags  behind  the  civil 
community  in  application  of  new — mostly  infonnation — technologies  and  inventions.  The  Air 
Force  has  no  shortage  of  good  ideas  on  how  to  apply  technology  to  solving  current  problems. 
There  is  a  growing  sense  of  frustration,  however,  among  the  operational  and  development 
community  on  how  to  bring  good  ideas  into  the  operating  environment.  Very  little  of  the  C  - 
related  technology  developed  by  the  Air  Force  Research  Laboratories  (AFRL),  from  the  Defense 
Advanced  Research  Projects  Agency  (DARPA),  or  from  the  Joint  Expeditionary  Force 
Experiment  (JEFX)  experiments  has  yet  transitioned  into  operational  C2  programs.  In  our 
recommendations  we  have  included  a  commentary  on  how  the  technology  transition  process 
could  be  put  on  a  fast-track  to  speed  technology  deployments  that  can  improve  C2ISR  operations. 

Leveraging  the  information  technology  revolution,  which  is  fueled  by  e-commerce,  to  enhance 
C“ISR  operations  will  require  the  Air  Force  to  consider  new  sources  for  technology.  Historically 
all  major  C2ISR  systems  have  been  developed  using  a  prime  integration  contractor.  In  our 
recommendations  we  have  also  addressed  how  the  Air  Force  can  benefit  by  reaching  out  to  other 
technology  development  sources  to  speed  the  development  and  deployment  of  next-generation 
C2ISR  capabilities. 
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4.2  Approach  and  Visits 

The  approach  selected  by  the  panel  for  evaluating  the  availability  of  suitable  technologies  for 
achieving  C  dominance  was  to  request  input  on  relevant  technology  efforts  from  technology 
leaders  in  industry  (commercial  and  defense),  from  universities  and  from  government  research 
facilities  including  AFRL,  DARPA,  the  National  Reconnaissance  Office  (NRO),  the  Defense 
Information  Systems  Agency  (DISA),  and  the  other  Services.  Input  was  also  provided  on 
operational  technology  needs  by  the  Aerospace  C  Intelligence,  Surveillance,  and 
Reconnaissance  Center  (AC2ISRC)  and  current  C2  programs  by  the  Electronic  Systems  Center 
(ESC).  Finally,  the  Technology  Panel  membership  was  selected  to  provide  a  breadth  of  expertise 
across  the  technology  areas  deemed  to  be  most  critical  to  meet  the  Air  Force’s  near-tenn  and 
longer-term  C  needs.  Table  4-1  lists  the  organizations  and  facilities  visited  during  the  course  of 
the  study. 

Table  4-1 .  Technology  Panel  Visits 


Technology  Panel  Visits 


Hurlbert  Field  20-21  March 

AF  C2  Vision,  Approach  &  Progress;  Maj  Gen  Perryman 
Roles  &  Contributions  of  ESC;  Lt  Gen  Kenne 
C2  as  a  Weapon  System;  Mr.  Barringer 

Battle  Management  From  Joint  STARS-Past  &  Future;  Col  Lindsley 
Past,  Present  &  Future  Contributions  of  the  AFC2TIG;  Col  Carr 
USAF  C2  Acquisition;  Brig  Gen  Obering 
C2  Battlelab  Process,  Accomplishment  &  Plans;  Maj  Swaney 
JEFX  2000;  Col  Carr 

Langley/AFC2ISR  10-11  April 

ACC  Lessons  Learned  In  Operation  Allied  Force;  Maj  Hampton 
AOC  as  a  Weapon  System;  Col  Joe  May 

AC2ISRC  C2  &  ISR  02  POM  Campaign  Plan  2000;  Col  Wayne  Ranne 
Managing  the  C2ISR  Enterprise;  Lt  Col  Joe  Martin 
Tactical  Data  Links  USAF  Interests  and  Way  Ahead;  Lt  Col  Mike  Balog 
Bridging  The  Gap:  Operational  To  Tactical  Art;  Col  Steve  Callicutt 
Distributed  Common  Ground  System  Program  Overview;  Mr.  Donald  Walker 
Global  Information  Grid  for  the  Warfighter;  Col  Jack  Fellows 

ISR  Battle  Management  (ISRBM)  Tool  Demonstration  Update;  Lt  Col  Ginny  Tonnesson 

Air  Force  Experimentation;  Lt  Col  Skip  Liepman 

Kosovo  Lessons  Learned;  Gen  John  P.  Jumper 

Theater  Battle  Management  Core  System;  Lt  Col  Kevin  Damato 

Time  Critical  Targeting  &  Real  Time  Information  In  The  Cockpit;  Lt  Col  David  Jones 

The  Limitations  of  Doctrine;  Gen  John  P.  Jumper 

NRO/DARPA  16-17  May 

NRO  Strategic  Thrusts  Integration  Program  Strategy;  Maj  Gen  Dickman 

Corporate  System  Engineering  Function;  Mr.  Broadwater 

Deputy  Director  for  Military  Support  Perspective;  Brig  Gen  Crawford 

EMIT  Perspective;  Brig  Gen  Sover 

Future  System  Perspective;  Mr.  Roche 

Communications  Perspective;  RADM  Fisher 

SIGINT  Perspective;  Mr.  Fitzgerald 

Information  Support  Strategy;  Mr.  Mahen 

Airbourne  Overhead  Interoperability  Office  Perspective;  Col  Wheeler 

Strategy  Gaming  and  Experimentation;  Mr.  Hernandez 

Kosovo  Lessons  Learned;  Col  Gill 

NRO  Analysis  Center  Studies;  Col  Jones 

Collection  Concept  Development  Center;  Mr.  Gibson 

DDB;  Dr  Mulari 

Langley/Fusion  Briefings  23-25  May 


Rome  Labs/ESC  12-15  June 

IF  Overview;  Mr.  John  Graniero 
Global  Awareness  Overview;  Mr.  John  McNamara 
Adaptive  Sensor  Fusion;  Mr.  Mike  Hinman 
Multiplatform  MTE  fusion;  Mr.  Jon  Jones 

GMTE  -  Ground  Moving  Target  Exploitation;  Lab  Mr.  Brian  O’Hern 

Dynamic  Data  Base;  Mr.  Pat  McCabe 

BROADSWORD;  Dr.  John  Salerno 

Joint  Targeting  Toolbox;  Mr.  Joe  Palermo 

Targets  Under  Trees  (TUT);  Mr.  Ed  Zelnio 

DP&E  Overview;  Dr.  Nort  Fowler 

Joint  Battlespace  Infosphere  (JBI);  Mr.  Rick  Metzger 

Effects  Based  Operations;  Mr.  Dan  Fayette/Dr.  Lemmer 

Intelligent  Agents;  Mr.  Jamie  Lawton 

JEFX  Activities;  Maj  Bob  Marmelstein 

SOF  Plan  Active  Templates;  Mr.  Dale  Richards 

Sensor-Decision  Maker-Shooter;  Mr.  Ken  Trumble/Derryl  Williams 

Datawall;  Mr.  Pete  Jedrysik/Lt  Quant 

GIE  Overview;  Dr.  Warren  Debany 

Link-16;  Mr.  Mark  Minges 

SATCOM/CDL  Activities;  Mr.  Walter  Hartman 

Airborne  Communications  (Node  and  Relay);  Mr.  Richard  Hinman 

MEMS/Ultracomm;  Mr.  Paul  Ratazzi 

Langley/ISR  Briefings  21-22  June 

SPAWAR/SWC  26-28  June 

Center  Overview/Vision  Brief/Command  Center  of  the  Future  (CCOF);  Tom  Kaye 

Commander  in  Chief  for  the  21st  Century;  Tom  Tiernan 

Global  Command  and  Control  System;  Jack  Gerrard 

Cognitive  Technologies;  Ken  Kaufman 

Strategic  Decision  Making  Under  Stress;  Guy  Leonard 

Distributed  Collaboration;  Lorraine  Duffy 

Horizontal  Integration  and  S&T  Technology  Integration;  Don  Johnson 

Information  Operations  Center  of  the  Future;  Lee  Zimmerman 

Information  Assurance  Experimentation;  Christine  St  Clair 

Tactical  Digital  Information  Links  (TADILS);  Janet  Bailey 

Common  Data  Link  Management  System;  Janet  Bailey 

TADILS  Foreign  Material  Sales  (FMS);  Greg  Lawrence 

Distributed  Engineering  Plant  (DEP);  Dave  Andersen 

Real  Time  Execution  Decision  Support  (REDS);  John  Me  Donell 

Automated  Communications  Management  System  (ACMS);  Sally  Norvell 

Location  of  GPS  Interference;  Fernando  Escobar 


Summer  Study  Final  Session  10-21  July 

Oracle  Corperation;  Mike  Lennon 

Sun  Microsystems,  JavaSoft;  Timothy  Lindholm 

TBMCS  Briefing;  Mike  Charron,  Rizwan  Jaka,  Howard  Able 
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4.3  Findings  and  Discussions 

The  Air  Force  vision  of  global  vigilance,  reach,  and  power  requires  assured  decision  dominance 
over  adversaries.  The  Air  Force  has  committed  to  strengthen  the  ability  of  commanders  to 
command  and  control  aerospace  forces  to  achieve  and  maintain  this  dominance.  The  opportunity 
exists  to  harvest  a  rich  and  diverse  array  of  technologies,  systems,  and  services  to  substantially 
enhance  the  ability  of  the  Air  Force  to  establish  and  maintain  this  essential,  dominant  C2 
capability.  Figure  4-1  summarizes  the  availability  of  technologies  either  from  commercial  or 
government  sources,  for  providing  key  capabilities  to  achieve  C2  dominance.  Figure  4-1  also 
indicates  the  panel’s  assessment  of  how  well  available  technologies  are  being  exploited  in  Air 
Force  C2  systems.  The  rationale  behind  this  assessment  is  included  in  the  following  sections  for 
each  key  capability  area  considered. 


Technologies 

COTS 

Available 

GOTS 

Available 

C2 

Exploitation 

Dynamic  Planning  and 
Execution 

® 

© 

® 

Connected,  Survivable, 
Reliable  Communications 

o 

® 

® 

Information  Fusion 

® 

® 

© 

Information  Assurance 

® 

® 

® 

Information  Management 

© 

® 

® 

Human-Machine 

Interaction 

© 

® 

© 

Enterprise  Systems 
Engineering 

© 

© 

© 

Green:  Some  Ready  Yellow:  Future  Potential  Red:  Not  Yet 

Figure  4-1.  Available  Technologies 


4.3.1  Dynamic  Planning  and  Execution 

Implementation  of  dynamic  planning  and  execution  (DP&E)  requires  a  shift  in  C2  focus  from 
scheduling  systems  to  planning  systems.  These  planning  capabilities  must  accommodate  the 
ever-present  dynamic  and  uncertain  nature  of  active  operations.  Some  of  the  dynamic  tasking 
requirements  associated  with  time-critical  targeting  are  described  in  Appendix  4D.1 3  These 
include  dynamic  tasking  of  both  sensors  and  shooters. 

DP&E  will  require  changing  to  interactive,  adaptive,  dynamic,  and  closed-loop  processes  as 
opposed  to  the  open-loop,  finite-time-horizon  planning  approach  used  in  earlier  C  systems. 


13  Appendix  4D  can  be  found  at  the  end  of  this  Volume. 
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Many  of  the  principles  developed  for  use  in  dynamic  control  system  design  can  be  applied  in 
developing  this  process. 

Achieving  C2  dominance  also  requires  maintaining  an  evaluation  of  the  opportunity  cost 
associated  with  real-time  reallocation  of  resources.  The  dynamic  nature  of  this  approach  also 
requires  that  the  impact  of  the  dynamic  nature  of  the  environment  (for  example,  weather)  be 
included  in  this  continuous  planning  process.  In  the  following  sections,  our  assessment  of 
available  technologies  is  provided  along  with  our  assessment  of  how  effectively  relevant 
technologies  are  currently  being  deployed  within  Air  Force  C2  systems. 

4.S.1.1  Commercial  Off-the-Shelf  (COTS) 

Examples  of  commercial  decision-making  tools  that  appear  applicable  to  many  DP&E  situations 
include  tools  used  in  banking  and  finance  as  well  as  airline  and  package-delivery  scheduling  and 
corporate  planning.  In  most  cases,  however,  the  military  decision-making  tasks  are  more 
demanding  and  complex  than  their  civilian  counterparts  in  the  number  of  degrees  of  freedom,  the 
scale  of  the  tasks,  the  temporal  dynamics  of  the  environment,  the  intensity  of  adversarial 
engagement,  and  the  impact  of  the  outcome.  As  a  result,  few  COTS  technology  solutions  are 
readily  applicable  to  the  Air  Force  DP&E  enterprise  beyond  general-purpose  office  automation 
suites  (for  example,  Microsoft  Office),  some  general-purpose  analysis  tools  (for  example,  SPSS 
and  MATLAB),  and  coordination  facilitation  tools  (for  example,  Lotus  Notes). 

43.1.2  Government  Off-the-Shelf  (GOTS) 

The  Air  Force,  in  concert  with  other  DoD  organizations  including  DARPA  and  the  other 
Services,  has  a  steady  stream  of  DP&E  research  programs  and  prototypes  in  various  stages  of 
maturity.  A  number  of  these  are  on  track  for  operational  deployment  (for  example,  the 
Worldwide  Aerospace  Route  Planner,  the  Joint  Defensive  Planner,  the  Air  Tasking  Order 
Execution  Management  Reports,  and  the  Joint  Targeting  Toolbox)  and  several  represent 
emerging  capabilities  that  need  to  be  pushed  along  the  pipeline.  Examples  include  the  planning 
and  scheduling  technologies  embedded  in  the  AFRL  Information  Directorate  (AFRL/IF) 
products  such  as  the  Advanced  Mobility  Scheduler  and  the  Campaign  Assessment  Tool.  Still 
further  out  are  capabilities  deployable  within  several  years,  including  the  Multi- Asset 
Synchronizer  being  developed  under  the  Advanced  ISR  Management  program  at  DARPA,  as 
well  as  knowledge-based  planning  technology  emerging  from  DARPA’ s  Active  Templates 
program  (run  by  AFRL/IF),  the  Attack  Operations  Decision  Aid  being  developed  by  ESC,  the 
AFRL  Air  Operations  Center  (AOC)  Systems  Status  Controller  and  Master  Caution  Panel  and 
Theater  Ballistic  Missile  Reasoner.  Many  of  these  prototypes  are  to  be  evaluated  as  Category  1, 
2,  or  3  JEFX,  or  by  special  Major  Command  (MAJCOM)  exercises  including  the  Air  Force 
Special  Operations  Command  (AFSOC)  and  the  Air  Mobility  Command  (AMC). 

4.3. 1.3  Deployment 

The  deployment  of  promising  technologies  into  operational  use  is  being  delayed  due  mainly  to 
the  lack  of  an  environment  promoting  direct  working  relationships  between  the  technology 
development  community  and  the  Air  Force  user  community  engaged  in  daily  practice  of  the  C2 
operational  art.  In  isolated  instances  where  this  relationship  exists  (for  example,  AFSOC  and 
AMC),  rapid  concurrent  technology  development  and  exercise  consistently  lead  to  direct 
insertion  into  the  user’s  ongoing  acquisition  programs. 
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An  effective  mechanism  to  realize  this  leveraged  developer-user  interaction  would  be  a 
sustained,  pro-active  C2  center  of  excellence  co-located  with  operational  users  engaged  in  the 
operational  art  with  network  connectivity  back  to  the  development  activities  at  AFRL, 

AC2ISRC,  and  C  BL.  The  emerging  JBI  Distributed  Testbed  will  have  nodes  at  these  locations 
and  could  serve  as  the  backbone  for  this  connectivity.  This  approach  would  enable  rapid 
evaluation  and  real-time  technology  steering  for  emerging  technology  while  lowering  barriers  to 
innovation  and  insertion. 

4.3.2  Connected,  Survivable,  Reliable  Communications 

Maintaining  connected,  survivable,  reliable  communications  is  essential  to  achieving  C~ 
dominance.  The  communications  systems  architecture  must  be  flexible  enough  to  benefit  from 
current  and  future  technologies  and  capabilities  and  must  also  provide  seamless  interoperability 
with  numerous  legacy  systems,  including  integration  and  enhancement  of  the  Link- 16  system. 
Widespread  use  of  bandwidth-efficient  modulation,  spread-spectrum  capabilities,  incorporation 
of  higher  frequencies,  and  proliferation  of  software  radios  are  examples  of  leveraged  technology 
insertion  candidates  that  can  enhance  robustness  to  provide  connected,  survivable,  reliable 
communications.  The  use  of  commercial  communications  systems  and  services  is  expected  to 
become  more  widespread,  and  enhanced  connectivity  to  smaller  units  within  a  more  mobile  Air 
Force  and  interoperability  with  other  Service  elements  will  remain  a  priority. 

The  scope  of  communications  considered  here  includes  intra-system  (networked  connectivity 
among  components  of  the  C2  system  itself)  and  extra-system  communications  from  the 
networked  elements  of  the  system  to  external  users  (such  as  aircraft)  and  from  external  users 
(such  as  aircraft  and  intelligence  sources). 

4.3.2. 1  COTS 

The  commercial  sector  is  investing  extensively  in  communications  systems  and  services,  many 
of  which  could  be  used  extensively  for  Air  Force  and  DoD  needs.  It  is  appropriate  to  recall  that 
much  of  this  current  investment  in  systems  and  services  is  based  on  technology  initially 
developed  as  a  result  of  research  funded  by  DoD.  Examples  are  numerous  and  include 
networking  protocols,  fiber  optic  technologies,  wireless  networks,  satellite  communications 
(SATCOM),  high-power  amplifiers,  low-noise  receivers,  integrated  circuits,  and  many  more. 
Much  of  the  current  investment  is  fueled  by  the  need  for  greater  bandwidth  and  is  driving  the 
installation  of  fiber  optic  networks  and  the  development  of  fiber  optic  components,  including 
wave  division  multiplexing.  Wireless  technology  is  another  major  area  of  investment.  This  is 
being  driven  by  the  expanding  use  of  cellular  systems  and  wireless  access  by  a  variety  of 
personal  digital  assistants. 

Intra-system  communications  support  the  network  used  by  the  C  system  for  internal  network 
communications.  COTS  solutions  exist  for  many  of  these  C2  requirements.  COTS  networking 
protocols,  including  Internet  Protocol  (IP),  ATM,  and  SONET  provide  connectivity  and 
interoperability.  Commercially  available  security  capability  is  sufficient  to  isolate  C2  networks 
from  the  secure  networks  they  ride  over  (for  example,  secure  sockets  as  used  by  TBMCS  and 
others).  Messaging  standards  are  also  available,  including  Extensible  Markup  Language  (XML), 
which  are  being  designed  to  facilitate  networked  data  transfer  between  information  systems. 
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Extra-system  communications  are  necessary  between  the  C  system  and  the  outside  world.  Most 
of  this  communication  traffic  will  be  carried  by  direct  radiated  radio  frequency  (RF)  or 
SATCOM  links.  Commercial  standards  for  these  links,  including  GSM-3,  IS-95,  and  VSAT, 
exist  and  are  suitable  for  many  DoD  C  needs. 

43.2.2  GOTS 

Current  Government  communications  systems  used  to  provide  “anytime,  anywhere  robust 
connectivity”  have  generally  been  unique  implementations  of  COTS  solutions.  GOTS  standards 
exist  primarily  because  the  commercial  standards  do  not  take  into  account  many  unique  DoD 
needs,  including  security,  low  probability  of  detection  and  interception,  and  survivability. 
Examples  of  these  GOTS  standards  are  numerous  and  include  Link- 16,  TADIL-J,  TADIL-B, 
Common  Data  Link,  TCDL,  and  others. 

4.3.23  Deployment 

Deployment  of  commercial  systems  and  services  for  satisfaction  of  C2  needs  will  increase.  It  is 
also  true  that  continued,  sustained  investment  to  satisfy  unique  C  mission  requirements  must 
continue.  The  combined  commercial  focus  on  near-term  technologies  and  government  focus  on 
longer-term  technologies  has  resulted  in  opportunities  for  government  investment  that  will 
enable  unique  and  unprecedented  advances.  A  number  of  the  most  highly  leveraged  investment 
opportunities  follow. 

Programmable  and  Software  Radios.  This  includes  programmable  waveforms  and 
programmable  spectrum  usage.  The  purest  form  of  this  is  the  software  radio,  which  has  no 
conventional  RF  demodulator  at  all  and  thus  has  unprecedented  flexibility  in  modulation  and 
spectrum.  The  Joint  Tactical  Radio  System  program  is  developing  a  digital  radio  that  will  store 
six  simultaneous  pre-programmed  waveforms.  Once  developed  and  in  widespread  usage,  this 
technology  offers  the  opportunity  to  develop  and  deploy  new  waveforms  and  spectrum  usage 
algorithms  to  meet  specific  jamming  and  channel  capacity  challenges.  In  addition  to  the 
component  technologies  needing  to  be  developed,  system-level  development  and  integration  will 
be  challenging.  The  ability  to  dynamically  deploy  these  new  waveforms  and  algorithms  in  near- 
real  time  will  require  the  development  of  more  adaptable  software  radios,  appropriate  transfer 
protocols,  and  supporting  infrastructure  and  policy. 

Exploiting  Commercial  and  National  Satellites.  Commercial  and  national  satellites  offer  the 
opportunity  to  communicate  with  aircraft  with  high  bandwidth  and  low  probability  of  detection. 
Much  of  the  technology  needed  to  do  this  has  been  developed,  but  much  work  remains  to  be 
done  in  designing  apertures  and  systems  that  are  more  cost-effective  to  integrate  into  aircraft. 
Another  high-value  development  is  to  design  apertures  and  radios  that  are  more  flexible.  Even 
though  the  cost  of  incorporating  a  new  communications  system  into  aircraft  will  inevitably 
remain  high,  this  flexibility  will  allow  us  to  adapt  communications  systems  to  reflect  changing 
C2  needs.  Additional  challenges  remain,  including  system  architecture  and  protection  of 
information.  A  flexible  infrastructure  architecture  is  needed  that  can  accommodate  the  specific 
commercial  or  national  capabilities  available  in  each  potential  area  of  operation.  Additionally, 
commercial  capabilities  at  any  given  point  in  time  will  vary,  depending  upon  many  factors 
totally  out  of  DoD’ s  control.  Achieving  this  flexibility  requires  continuing  the  dialog  with  the 
national  community.  It  is  essential  to  add  a  dimension  to  this  dialog,  namely  to  establish  a 
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meaningful  and  sustained  dialog  with  the  commercial  sector  to  develop  a  current  assessment  of 
commercial  systems  and  capabilities. 

Integrated  Network  Architectures.  This  has  long  been  a  challenge:  Each  platform — aircraft, 
satellite,  ship,  land  vehicle,  and  fixed  structure — can  be  a  node  in  a  global  communication  grid, 
very  much  like  a  cellular  network  today.  Significant  issues  with  access  control,  adjudicating 
usage,  and  even  priority  usage  of  commercial  systems  in  a  national  emergency  all  remain. 

Link- 16  Follow-On.  Even  though  Link- 16  will  not  be  completely  fielded  for  several  more 
years,  it  is  already  an  old  technology.  Significant  enhancements  are  required  to  meet  even 
today’s  requirements.  Specifically,  link  latency  must  be  reduced  below  1  millisecond  to  enable 
new  targeting  technologies  to  be  employed,  the  system  must  be  made  rapidly  reconfigurable  to 
allow  the  addition  of  assets  during  operations,  and  the  overall  throughput  must  be  increased. 

Integration  With  Legacy  Systems.  As  we  field  new  systems,  we  must  take  legacy  systems  into 
account.  It  is  generally  unaffordable  to  replace  an  entire  communications  infrastructure  at  once, 
due  to  the  massive  investment  in  legacy  terminals.  Thus  new  systems  must  be  fielded  in  a  way 
that  allows  continued  support  for  older  systems  during  an  orderly  transition.  We  need  to  develop 
more  cost-effective  ways  to  do  this. 

Bandwidth-Efficient  Communications.  Bandwidth  is  already  limited  today,  and  tomorrow’s 
C  systems  will  use  far  more.  In  a  bandwidth-constrained  environment  we  need  to  develop  new 
techniques  for  packing  more  data  into  the  scarce  bandwidth  available.  These  techniques  include 
maximizing  frequency  reuse  (for  example,  systems  such  as  the  Airborne  Communications  Node, 
Large  Aperture  Spacecraft,  Mobile  User  Objective  System,  ACeS,  and  THURAYA  are  all 
designed  to  do  this),  demand-access  multiple-user  techniques,  bandwidth-on-demand  systems, 
and  bandwidth-efficient  modulation  techniques.  Finally,  exploration  of  trellis  coding  or  soft- 
coding  techniques  (the  best  known  is  called  Turbo-Coding)  to  reduce  required  bandwidth  will  be 
a  very  fertile  research  area. 

4.3.3  Information  Integration  and  Fusion 

Combining  information  to  estimate  or  predict  the  state  of  the  battlespace,  known  as  fusion  (or 
data  fusion),  is  still  at  a  primitive  stage.  There  is  no  consistent  and  meaningful  definition  or 
conceptualization  of  the  “battlefield  information  state”  that  the  fusion  process  is  intended  to 
estimate  or  identify  and  that  must  underlie  any  meaningful  definition  of  the  common  operational 
picture. 

While  the  main  focus  of  fusion  and  situation  and  global  awareness  (S/GA)  is  upstream  from  the 
sensors  that  provide  the  raw  “probes”  into  the  battlefield,  a  critical  role  of  fusion  is  to  identify 
and  quantify  sensing  shortfalls — that  is,  areas  in  which  the  available  information  is  simply 
inadequate  for  the  production  of  fused  info-products  of  desired  or  required  quality.  The  Air 
Force  should  make  sure  that  the  perfonnance  assessment  portion  of  the  main  recommendation 
includes  identifying  such  shortfalls,  as  well  as  the  associated  task  of  working  with  sensing 
technologists  to  identify  options  for  overcoming  these  information  shortcomings.  The  advantage 
of  doing  it  in  this  manner  is  that  the  value  of  new  sensors  is  assessed  in  vivo,  as  embedded 
capabilities  that  affect  S/GA  performance,  rather  than  in  isolation. 
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433.1  COTS 

Commercial  industry  has  developed  and  is  continuing  to  develop  applications  to  perform  data 
mining.  This  involves  defining  metadata  standards  that  are  critical  to  the  fusion  process. 
Regrettably,  enough  differences  exist  between  the  problems  being  solved  in  the  commercial 
world  and  the  problem  of  characterizing  a  time-varying  battlespace  that  there  is  limited 
applicability. 

433.2  GOTS 

Some  existing  fusion  and  other  S/GA  technologies  contain  needed  and  useful  capabilities  that 
can  be  fielded  in  the  near  tenn  to  provide  enhanced  C"  capabilities.  These  need  to  be  identified, 
cataloged,  tested,  and  quantified  in  terms  of  perfonnance  and  pushed  along  the  transition 
pipeline  and  ported  to  the  C  infrastructure. 

Other  existing  fusion  and  other  S/GA  technologies  are  not  quite  as  far  along  as  the  first  set  to  be 
identified  under  S/GA-1,  but  can  provide  deployable  capabilities  within  5  years.  These  need  to 
be  identified,  prioritized,  and  then  acted  upon.  Since  some  of  these  capabilities  are  being 
developed  by  other  organizations  (such  as  DARPA  or  other  Services),  the  “action”  here  must  not 
simply  involve  internal  Air  Force  activity  but  must  also  involve  either  working  with  (or  making  a 
case  to)  DARPA  and  working  with  other  Services  to  develop  joint  capabilities. 

Among  the  capabilities  that  fall  into  this  class  are  the  All-Source  Track  and  Identify  Fusion 
component  of  DARPA ’s  Dynamic  Database  program,  but  there  are  many  other  possibilities  to  be 
cataloged  and  prioritized.  Note  that  while  the  Air  Force  has  done  a  very  good  job  of  working 
with  DARPA  in  the  past — in  the  area  of  ground  moving-target  indication,  for  example — even 
more  can  be  done  if  the  Air  Force  strengthens  its  technology  transition  pipeline  so  that,  in 
DARPA’ s  eyes,  it  becomes  a  reliable  transition  path  for  DARPA  technology  as  well  as  a  trusted 
source  for  identifying  technology  needs  that  drive  future  DARPA  programs. 

4333  Deployment 

Only  systems  that  combine  small  numbers  of  inflexible  types  of  data  are  being  deployed.  As 
more  effective  multi-source  fusion  engines  become  available,  a  substantially  greater  deployment 
funding  line  will  be  warranted. 

Some  fusion  capabilities  are  already  (or  are  on  their  way  toward  being)  operational  in 
contingency  theater  automated  planning  system  or  TBMCS  and  in  systems  of  other  Services  (the 
All  Source  Analysis  System,  the  Tactical  Event  Systems,  and  the  Joint  Maritime  Command 
Information  System/Global  Command  and  Control  System-Navy).  In  addition,  emerging 
capabilities  (at  AFRL  and  DARPA)  need  to  be  pushed  along  the  pipeline.  To  be  sure,  the 
capabilities  available  do  not  represent  a  final  or  100  percent  solution.  However,  they  do 
represent  important  functionality  and  the  point  of  departure  for  any  enhancements.  Not  only 
should  these  existing  capabilities  be  ported  to  the  JBI  infrastructure,  but  their  capabilities  need  to 
be  codified  and  quantified.  Doing  this,  however,  will  require  the  development  of  a  dearly  needed 
discipline,  essentially  that  of  providing  a  “spec  sheet”  for  capabilities.  Very  roughly  speaking, 
what  we  have  in  mind  here  is  the  equivalent  of  the  specs  one  finds  for  electronic  components, 
which  quantify  the  requirements  or  constraints  each  capability  component  has  on  its  inputs  and 
the  resulting  quality  of  the  outputs  it  produces.  An  example  here  is  track  accuracy  or  continuity 
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as  a  function  of  measurement  revisit  rates,  false  alarm  rates,  detection  probabilities,  and  range  or 
cross-range  accuracies. 

As  a  related  comment,  we  should  point  out  that  one  of  the  impediments  to  the  technology 
pipeline  is  the  resistance  to  fielding  70  percent  solutions:  rather  than  being  viewed  as  providing 
additional  capability,  developers  are  criticized  for  leaving  out  one  particular  additional  2  percent 
or  another,  which  diverts  effort  from  getting  some  capability  out  to  the  user  and  then  using  that 
as  a  launching  point  for  enhancements.  This  represents  a  change  in  culture  and  values  in  dealing 
with  capabilities  and  also  points  to  the  need  for  a  requirements  process  that  neither  leads  nor  lags 
development  and  deployment. 

4.3.4  Information  Assurance 

DISA  estimates  that  there  are  250,000  attacks  on  DoD  computer  systems  every  year.  Some  of 
this  activity,  when  directed  against  DoD  systems,  might  include  information  warfare  (IW) 
actions  to  “prepare  the  battlefield”  for  future  interference  with  U.S.  activity.  We  can  expect 
targeted  attacks  on  DoD  systems  to  increase  during  hostilities.  Both  the  threat  and  our 
vulnerability  will  increase  with  increasing  connectivity  among  military  systems  and  to  civilian 
networks.  Thus,  vulnerabilities  in  the  networking  technology  or  in  any  connected  system  can  be 
exploited  by  anyone  anywhere  in  the  world  to  penetrate  and  corrupt  DoD  systems.  Another 
source  of  vulnerability  arises  from  the  increased  reliance  on  commercial  products.  Commercial 
security  is  neither  designed  nor  intended  to  withstand  IW  attacks,  and  a  large  number  of 
exploitable  flaws  and  attacks  on  commonly  used  products  are  known  to  a  wide  community. 
Furthermore,  the  increased  homogeneity  that  results  from  the  nature  of  today’s  commercial 
computer  system  marketplace  leaves  DoD  open  to  attacks  that  can  quickly  affect  a  large 
percentage  of  its  operations.  DoD  also  depends  on  vulnerable  commercial  infrastructures  such  as 
telephone  networks  that  although  highly  reliable  were  not  designed  to  withstand  IW  attack. 

There  are  numerous  risks  to  C  operations.  Vigilance  is  required  on  the  part  of  system  designers, 
implementers,  managers,  and  users  to  anticipate  security  vulnerabilities  and  to  address  them  with 
technical  or  procedural  means.  Constant  awareness  that  portions  of  the  system  may  be 
compromised  will  help  warfighters  react  appropriately  to  situations.  Backup  plans  should  be 
developed  for  the  most  likely  compromise  scenarios,  and  warfighters  should  be  trained  in  these 
procedures.  Some  of  the  steps  that  can  be  taken  to  provide  information  assurance  are 
summarized  in  Appendix  4D.14 

4.3.4.1  COTS 

To  be  affordable,  Air  Force  C  systems,  including  protection  functions,  will  be  built  largely  from 
commercial  software  and  hardware  computing  and  networking  components.  These  commercial 
products  contain  numerous  security  vulnerabilities,  and  as  they  are  discovered,  these 
vulnerabilities  are  routinely  posted  to  frequently  accessed  websites  (for  example,  Bugtraq). 
Attacks  are  developed  against  many  of  these  vulnerabilities,  and  software  tools  to  carry  out  the 
attacks  are  posted  to  hacker.  Commercial  security  products  are  not  built  to  withstand  the 
strength  of  attack  that  can  be  expected  for  military  systems,  but  to  provide  a  degree  of  strength 
appropriate  for  many  business  operations.  Known  vulnerabilities  in  these  security  products,  as 
well  as  attacks  exploiting  them,  are  also  posted  on  the  Web.  Vendors  may  respond  by  issuing 


14  Appendix  4E  can  be  found  at  the  end  of  this  Volume. 
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patches  (which  may  take  weeks)  or  correcting  the  problems  in  scheduled  new  product  releases 
(which  can  take  months),  resulting  in  a  period  of  exposure  during  which  procedural  workarounds 
must  be  employed  to  reduce  risk  as  far  as  possible.  Most  system  operators  may  not  be  aware  of 
the  discovered  vulnerabilities  in  the  products  they  are  using  or  of  the  availability  of  procedural 
workarounds  or  patches. 

4. 3.4.2  GOTS 

In  recent  years,  DARPA  and  other  agencies  have  funded  research  in  information  assurance  that 
has  resulted  in  some  promising  technologies  that  should  be  evaluated  for  use  in  Air  Force  C2 
systems.  Examples  include  encrypted  e-mail,  secured  protocols,  better  intrusion-detection 
components,  digital  signatures  on  software,  early  versions  of  wrapper  generation  toolkits, 
prototype  local  intrusion  detectors,  and  a  framework  for  coordination  of  intrusion  detection  and 
response.  AFRL  has  participated  in  the  development  of  many  of  these  technologies  and  could  be 
funded  to  evaluate  them  and  select  the  most  promising  for  maturing  and  transitioning  into  the  Air 
Force.  DARPA  technologies  available  for  such  treatment  are  summarized  in  the  tables  included 
in  Appendix  4D.  In  addition,  DARPA  has  integrated  several  of  these  technologies  in  areas  of 
prevention,  detection  and  response,  and  security  management  for  command,  control, 
communications,  computers,  and  intelligence  information  systems. 

Because  of  the  large  shortfall  of  current  security  technologies  relative  to  needs,  the  DoD  research 
community  is  continuing  to  focus  on  several  areas  not  being  addressed  by  industry.  These 
include 

•  Intrusion  assessment  to  distinguish  serious  targeted  attacks  on  critical  systems  of  high  concern 
from  other  attacks  of  lesser  concern. 

•  Technologies  for  intrusion-tolerant  systems,  to  maximize  a  critical  system’s  ability  to  keep  on 
providing  service  despite  successful  attack  and  partial  system  compromise.  Component 
technologies  could  include  intrusion  detection,  protocols  that  allow  systems  to  react  to  detected 
events,  algorithms  to  redirect  resources  to  the  most  important  tasks  and  whose  behavior  is 
difficult  for  an  adversary  to  predict,  and  techniques  for  reconfiguring  to  a  state  not  susceptible  to 
the  original  attack. 

•  Technologies  to  limit  an  attacker’s  ability  to  carry  out  denial-of-service  attacks. 

•  Technologies  to  allow  existing  and  legacy  systems  to  be  retrofitted  with  some  security  and 
reliability  functionality. 

In  addition  to  these,  research  is  needed  in  areas  of  mobile  code  security,  extending  the 
capabilities  of  virtual  private  networks,  and  dependability.  There  is  also  a  need  to  develop  DoD- 
specific  solutions  for  areas  that  industry  is  not  addressing  because  there  are  no  common 
commercial  analogs — for  example  in  the  area  of  tactical  networks. 

4. 3. 4. 3  Deployment 

The  high  rate  of  release  of  new  products  and  product  upgrades  means  that  at  any  given  time  there 
may  be  no  common  software  configuration  across  Air  Force  C2  systems.  With  each  new  product 
and  product  release  comes  the  need  to  keep  up  to  date  on  product  vulnerabilities  and  fixes.  In 
addition,  policy  must  be  generated  about  acceptable  and  safe  product  configurations,  and  these 
configuration  mandates  must  be  monitored  and  enforced  across  the  Air  Force.  Failure  to  do  so 
will  result  in  unnecessary  exposure  to  vulnerabilities.  In  addition,  these  products  have  many 
unknown  vulnerabilities  that  will  be  discovered  during  their  lifetimes.  Generally,  due  to  product 
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size  and  complexity,  it  is  not  possible  to  discover  all  vulnerabilities  in  advance,  no  matter  how 
much  testing  is  perfonned.  Thus,  all  components  must  be  treated  as  vulnerable,  and  systems  that 
use  these  components  must  be  designed  with  the  premise  that  there  may  be  security 
vulnerabilities  in  any  system  component.  Even  when  security  functionality  is  designed  into 
commercial  products  and  services,  this  security  is  generally  weaker  than  that  required  for  Air 
Force  needs. 

This  means  the  Air  Force  must  be  able  to  design — from  insecure  components  and  services — 
systems  that  will  be  secure  against  anticipated  threats.  While  the  security  research  community 
has  long  recognized  the  need  for  viable  approaches  to  building  secure  systems  from  insecure 
components,  very  little  is  known  about  how  to  do  this,  and  secure  system  design  remains  an  ad 
hoc,  poorly  understood  discipline.  The  notion  that  it  is  not  possible  to  discover  all  vulnerabilities 
and  use  this  infonnation  to  guide  a  protection  strategy  is  contrary  to  current  thinking  in  DoD, 
where  the  emphasis  is  on  vulnerability  discovery,  so  that  appropriate  protections  can  be  placed  to 
counter  these  vulnerabilities.  This  popular  “vulnerability  discovery”  approach  puts  protections  in 
place  only  where  there  are  known  vulnerabilities.  But  because  there  is  no  way  that  all 
vulnerabilities  can  be  discovered,  such  an  approach  will  leave  the  system  unprotected  from  its 
unknown  exploitable  vulnerabilities,  which,  if  discovered  at  all,  will  be  discovered  only  during 
system  operation  throughout  the  lifetime  of  the  system. 

This  is  a  dangerous  situation,  because  an  adversary  may  well  discover  and  exploit  some  of  these 
vulnerabilities  that  are  still  unknown  to  the  Air  Force.  In  fact,  the  situation  is  asymmetric, 
because  a  determined  adversary  can  decide  which  part  of  the  system  it  wants  to  manipulate  or 
exploit,  purchase  the  commercial  products  used  in  that  part  of  the  system,  and  spend  many 
months  deconstructing  these  products  to  discover  vulnerabilities  that  can  be  profitably  and 
surreptitiously  exploited.  While  such  an  approach  is  clearly  affordable  by  an  adversary,  it  is  not 
affordable  as  a  defense,  since  the  defender  would  have  to  perfonn  a  costly  analysis  for  every 
system  component,  whereas  the  adversary  can  pick  and  choose  its  focus  of  attack. 

This  means  that  red  teaming  and  vulnerability  assessments  cannot  guide  a  protection  strategy  (as 
in  “penetrate  and  patch”).  A  safer  strategy  is  to  assume  that  every  system  component  contains 
unknown  security  vulnerabilities  that  can  be  exploited  by  an  adversary.  Where  to  place 
protections  against  such  unknown  vulnerabilities  will  depend  on  an  analysis  of  the  consequences 
of  any  of  these  unknown  vulnerabilities’  being  exploited.  In  designing  protections,  it  must  also 
be  kept  in  mind  that  the  protections  themselves  can  contain  unknown  exploitable  vulnerabilities, 
so  that  layers  of  protection  may  be  appropriate,  depending  on  the  estimated  consequences  of  an 
attack. 

4.3.5  Information  Management 

The  concept  of  information  management  (IM)  can  be  developed  from  Office  of  Management  and 
Budget  Circular  A-130’s  definition  of  it  as  the  planning,  budgeting,  manipulation,  and  control  of 
information  throughout  its  life  cycle  (for  example,  creation  or  collection,  processing, 
dissemination,  use,  storage,  and  disposition).  From  this  relative  high-level  view,  five  major 
functions  of  the  infonnation  management  system  (IMS)  can  be  derived.  The  IMS  must 
implement  the  commander’s  policies  for  access,  flow,  quality  of  service,  and  security 
(information  assurance).  To  implement  the  access  and  flow  attributes  of  policy,  a  transport 
management  function  needs  to  span  the  communication  level  of  the  enterprise.  Because  many  of 
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the  information  sources  represent  both  legacy  systems  and  services  provided  by  other 
organizations,  the  IMS  must  provide  data  (information)  transformation  functions.  The  fourth 
function  provides  basic  management  of  awareness,  access,  retrieval,  delivery,  and  dissemination 
of  information  across  multiple  security  environments.  The  last  function  is  infonnation  assurance 
across  all  functions  within  the  IMS. 

4.3.5. 1  COTS 

COTS  technologies  exist  to  implement  many  of  the  C  IM  processes,  as  the  commercial 
requirements  are  similar  to  those  within  DoD.  Operating  systems  such  as  Solaris  and  Windows 
NT,  messaging  languages  such  as  XML,  transfer  protocols  such  as  Transmission  Control 
Protocol/IP,  and  scripting  languages  are  available  and  constantly  being  improved.  Data  base 
applications  and  storage  applications  are  widely  available  as  well.  Virtually  all  information 
management  hardware  (workstations,  servers,  storage  devices)  is  currently  COTS,  and  there 
seems  little  reason  to  change  this.  Commercial  markets  that  will  require  the  higher  levels  of 
information  management  services  have  not  and  may  not  develop. 

4.5.5.2  GOTS 

GOTS  solutions  that  are  being  developed  are  generally  tailored  versions  of  COTS  solutions.  The 
premier  example  of  this  is  the  Defense  Information  Infrastructure  Common  Operating 
Environment,  which  consists  of  specific  versions  of  COTS  operating  systems  and  applications 
grouped  together  with  guaranteed  compatibility  and  a  certification  process  for  applications.  A 
notable  exception  to  this  rule  is  the  DARPA  IMS  model,  which  has  been  partially  implemented 
by  DISA  as  the  Infonnation  Dissemination  Management  (IDM)  program.  This  IDM  service  has 
been  deployed  in  European  Command,  Pacific  Command,  and  Central  Command  to  support 
introduction  of  the  Joint  Broadcast  Service  and  the  Global  Broadcast  System.  IDM  is  also  a  key 
element  of  the  JBI  Wright  Flyer  project  at  ESC.  The  IMS  is  not  an  alternative  to  other  services 
within  the  JBI,  but  provides  a  meta-service  across  the  entire  enterprise.  As  the  JBI  leading-edge 
spiral  is  constructed,  the  IMS  must  be  the  first  service  implemented  to  allow  other  services  to  be 
integrated  as  they  are  deployed.  AC2ISRC  should  develop  the  concept  for  IMS  and  become  the 
operational  manager  for  IMS  within  the  JBI  leading-edge  spiral 

4.3. 5.3  Deployment 

Deployment  of  COTS  and  GOTS  IM  solutions  tend  to  lag  behind  the  state  of  the  art.  For  C2  to 
grow  beyond  small  regional  conflicts  (Bosnia,  Kosovo,  etc.)  and  integrate  global  sources  of 
information  (air/space  reconnaissance,  air/space  surveillance,  logistics,  weather,  etc.),  the  Air 
Force  must  manage  the  access,  flow,  and  delivery  of  information  as  an  enterprise-scale  activity. 
IM  is  an  illusive  concept.  We  know  it  keeps  the  Internet  operating  and  allows  delivery  of  e-mail 
anywhere  in  the  world  with  just  a  name  and  an  Internet  service  provider,  and  yet  as  the  Air  Force 
considers  the  development  of  the  JBI,  the  role  of  IM  is  not  understood,  and  there  no  agreement 
on  definition  or  operational  concept.  The  AC2ISRC  should  partner  with  DARPA,  DISA,  and 
NRO  to  continue  the  development  of  IMS  capabilities  needed  to  provide  and  manage 
information  within  the  JBI.  Recommendations  on  how  to  speed  technology  deployment  into 
operational  applications  are  included  in  Section  4.4. 
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4.3.6  Human-Machine  Interaction 

2 

This  is  defined  as  the  elements  of  the  C  system  that  address  the  bi-directional  interface  between 
human  and  machine.  Specific  concerns  of  this  interaction  include  handle-ability  (ease  of  use 
plus  portal  tailoring)  of  the  C2  interface,  synchronized  collaborative  operation  of  the  hybrid 
(human  and  machine)  decision  support  system,  and  a  flexible  command  structure,  wherein  a 
commander  contributes  abstract  reasoning  to  a  quasi-autonomous  decision  system  and  can  drill 
down  if  required  or  defer  if  desired. 

To  clarify,  a  decision  support  system  with  flexible  command  structure  is  intended  to  harness  the 
analytical  processing  capabilities  of  autonomous  systems  to  present  the  commander  with  a 
rational  plan  for  actuation.  If  necessary,  the  execution  of  planning  can  become  transparent  to  the 
human  being — that  is,  humans  can  remove  themselves  from  the  C2  loop  after  providing  an 
abstract  objective  (the  art  of  command)  while  the  machine  determines  course  of  action  (the 
science  of  control).  The  human  can  then  be  re-injected  at  any  point  in  the  C  hierarchy  if 
desired.  For  example,  human  participation  may  be  appropriate  in  circumstances  where  time- 
consuming  measured  reasoning  can  be  accommodated,  or  even  where  instinctual-type  (assess- 
react)  behavior  is  required,  while  autonomous  decision  execution  may  be  used  in  situations 
where  learned  (if-then)  or  analytically  optimal  decisions  provide  rapid  response. 

Given  decision  making  in  a  centralized  or  distributed  context,  distribution  of  both  status  and 
command  intent  must  be  considered  throughout  the  hybrid  C2  system.  These  operations  should 
also  occur  in  a  manner  that  allows  synchronization  of  executed  events  in  time,  space,  and 
purpose. 

Furthermore,  to  accommodate  varying  styles  of  command,  the  interface  from  human  to  machine 
can  be  portal-tailored  to  individual  preferences.  The  individualized  interfaces  should,  however, 
be  based  on  a  common  functionality  to  avoid  disrupting  system  stability  in  pursuit  of  system 
performance. 

4.3.6. 1  COTS 

Several  technologies  are  available  for  leverage  in  the  human-machine  interaction  element  of  C2. 
Relevant  commercial  technologies  available  for  near-term  application  include  automated  speech 
recognition  for  transparent  interface  and  3D  audio,  separating  voices  in  physical  space  for 
seamless  identification  of  decision  actors.  Commercial  technologies  available  for  future 
application  include  untethered  C2  for  wireless  interface,  large-screen  seamless  projection,  and 
flat  panel  displays  (see  Chapter  5). 

4.5.6.2  GOTS 

Government  technology  efforts  have  seeded  a  number  of  cited  commercial  technologies,  but 
GOTS  is  extremely  limited  in  terms  of  existing  and  available  technologies  for  C  application. 
More  specifically,  we  believe  that  Air  Force  recognition  of  human-machine  interaction  as  a 
technology  area  for  C  investment  is  essentially  absent.  Certainly  the  importance  of  training  is 
recognized.  However,  there  are  very  important  issues  well  beyond  training  that  are  barely 
articulated  and  for  which  capabilities  are  either  severely  inadequate  or  completely  missing. 
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4.3. 6.3  Deployment 

Although  COTS  technologies  are  available  for  translation  to  government  systems,  very  few  have 
been  exploited  for  operational  deployment.  This  inadequacy  is  manifested  in  the  functioning  of 
today’s  AOC,  which  operates  in  an  ad  hoc  fashion  based  on  a  decision  cycle  with  many  humans 
in  the  loop.  As  with  many  high-perfonnance  systems,  the  human  has  here  become  a  limiting 
factor  in  C  due  to  constrained  reaction  times.  Unfortunately,  it  is  not  possible  to  increase  human 
capabilities  in  the  loop  by  increasing  the  number  of  humans  involved — the  human  being  is  not 
scaleable.  In  the  presence  of  an  increasingly  high  operations  tempo  and  increasingly  high- 
performance  mixed-autonomy  systems,  the  decision  cycle  has  become  vulnerable  to  lack  of 

9 

coordination  and  disintegration.  To  maintain  both  system  stability  and  performance,  future  C 
must  consider  the  human-machine  interaction  a  priori  in  terms  of  interface  usability, 
synchronized  hybrid  operations,  and  flexible  command  support. 

4.3.7  Enterprise  Systems  Engineering 

Enterprise  systems  engineering  is  the  set  of  integrated  processes  and  resources  that  enable 
organizations  to  effectively,  rapidly,  and  transparently  perform  their  missions  across  functions 
and,  where  necessary,  across  organizational  boundaries.  There  are  three  aspects  of  enterprise 
systems:  First  is  the  set  of  automated  applications  for  the  end;  these  support  the  operations  the 
end  user  or  customer  wishes  to  perform.  Second  is  the  automated  integration  of  these 
applications  into  the  business  processes,  transactions,  and  analyses  of  the  enterprise  providing 
products.  Third  is  integrated  information  sharing  across  and  management  of  supply  network 
resources  and  organizations. 

A  five-layer  business  model  to  guide  this  process  is  summarized  by  the  following  steps: 

•  Vision:  What  the  result  will  be  of  the  effort — how  the  effort  will  positively  affect  the  entire 
business  mission,  under  what  (emerging)  conditions. 

•  Business  model  or  value  proposition:  How  the  system  and  practices  that  it  helps  implement 
will  add  value  toward  achieving  the  vision. 

•  Strategy:  What  steps,  aspects,  or  priorities  guide  the  development  and  implementation. 

•  Business  (operational)  process  and  rules:  What  re-engineered  processes  will  be  embodied  in 
and  facilitated  by  the  information  system,  and  what  rules  apply  (access  to  information  or  services, 
responsibilities,  authorities,  etc.). 

•  Organizational  design:  What  new  roles,  activities,  interactions,  organizational  forms,  and 
practices  are  required  to  carry  out  the  vision  and  business  models  and  to  support  and  evolve  the 
new  information  environment. 

4. 3.7.1  COTS 

The  best  models  for  the  most  relevant  dynamics  and  functionality  can  be  found  in  e-enabled 
business:  e-commerce  and  business-to-business  enterprises.  We  have  specific  examples  in 
industry  where  systems  have  been  constructed  as  proprietary  systems  over  private  networks,  and 
we  are  beginning  to  see  many  examples  where  these  systems  are  integrated  using  COTS 
components  and  open  standards  for  data  interoperability  communicating  over  the  Internet.  The 
COTS  components  are  typically  selected  and  integrated  based  on  an  explicit  value  proposition 
for  which  the  components  and  the  enterprise  functionality  are  then  customized. 
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These  three  aspects  of  enterprise  systems  engineering  enable  the  e-business  to  supply  customized 
goods  and  services  to  users  on  an  optimized  timeline,  as  well  as  to  optimize  processes  and 
inventory  across  the  entire  supply  network  (sometimes  called  a  value  net).  The  three  key 
technical  features  that  make  up  the  aspects  are  (1)  process  re-engineering  to  optimize  throughput, 
responsiveness,  and  perfonnance  of  the  value  net;  (2)  data  and  metadata  interoperability  across 
the  network  (typically  using  XML  and  mapping  tools),  which  may  be  provided  in  real  time  or  as 
aggregated  data  or  reports;  and  (3)  automated  tools  to  customize  presentation  of  data  and 
customize  processes  offered  to  the  customer,  based  on  underlying  business  rules. 

Three  things  enable  the  technical  side  of  enterprise  systems:  reengineered  business  processes, 
support  of  these  processes  with  customizable  software  components,  and  formal  data 
interoperability.  Process  re-engineering  within  the  retail  organization  and  across  the  value  net  is 
performed  to  optimize  throughput,  responsiveness,  and  perfonnance  of  the  value  net.  Data  and 
metadata  interoperability  across  the  network  (typically  using  XML  and  mapping  tools  to 
translate  among  data  dictionaries)  supports  data  sharing,  which  may  be  provided  in  real  time  or 
as  aggregated  data  or  reports.  Finally,  automated  tools  must  be  developed  to  customize  the 
presentation  of  data  and  the  processes  offered  to  the  customer,  based  on  underlying  business 
rules. 

A  classic  example  of  enterprise  systems  engineering  with  a  customer  portal  web  presence  can  be 
found  at  Amazon.com.  Walmart  with  its  anticipatory  and  collaborative  planning  functionality, 
and  General  Electric  with  its  proprietary  back-end  value  net  integration  systems,  are  long¬ 
standing  examples  of  enterprise  system  engineering  in  traditional  businesses.  They  have  been 
joined  by  Ford  and  International  Harvester,  among  others,  which  are  using  web-enabled  back 
end  business  integration. 

4. 3.7.2  GOTS 

An  enterprise  system  for  C  would  enable  the  rapid  initial  preparation  (predictive  battlespace 
analysis),  strategy,  planning  and  execution,  and  would  support  rapid  replanning  and  time-critical 
targeting.  Although  there  are  examples  of  integration  of  functionality  within  some  DoD 
organizations,  and  common  platforms  with  shared  applications,  we  could  discover  no  true 
enterprise  systems  engineering  efforts  that  would  provide  a  basis  for  development  of  a  C“ 
enterprise  system.  Although  elements  of  functionality  that  are  useful  in  the  C2  mission  have 
been  identified  and  may  soon  be  available  (elements  in  TBMCS,  for  instance),  there  is  no  true 
componentization  of  functionality,  no  interoperable  data  or  metadata  standards,  and  insufficient 
capture  and  characterization  of  operational  processes.  There  has  been  little  or  no  cross- 
organizational  enterprise  process  analysis  and  engineering,  or  cross-organizational  data 
interoperability  development.  An  enterprise  system  enables  the  seamless  coordination  of 
processes  across  organizational  or  functional  units  to  achieve  an  enterprise  goal. 

4. 3. 7. 3  Deployment 

The  approach  of  choice  clearly  is  to  use  COTS  and  build  to  a  set  of  open  commercial  standards. 
However,  COTS,  middleware,  and  open  standards  are  only  a  beginning.  The  most  flexible  and 
robust  approach  to  creating  an  open  architecture  is  a  layered  approach,  where  a  high  degree  of 
platform  independence  and  component  autonomy  can  be  achieved,  in  contrast  to  a  “Microsoft 
strategy,”  which  tightly  couples  functionality  from  operating  system  through  presentation 
technology.  An  architecture  strategy  must  be  developed  to  support  and  unify  the  spiral 
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development  process  and  to  guide  implementation  choices.  Flexibility,  expandability,  and  the 
rapid  incorporation  of  new  functionality  are  best  served  by  a  composable  component  services- 
based  architecture  using  COTS  and  organizing  around  commercial  component  and  web 
standards — Java,  Hypertext  Markup  Language  (HTML),  XML,  and  standard  wrapping 
technologies.  One  trap  that  should  be  avoided  is  the  use  of  conventional  system  integrator 
approaches  that  tie  operations  and  maintenance  (O&M)  to  a  custom  code  base  not  maintainable 
by  multiple  vendors. 

A  final  pitfall  to  avoid  is  the  practice  of  regarding  legacy  systems  as  the  foundation  for  future 
architectural  choices — that  is,  allowing  existing  system  architectures  to  dominate  the  evolution 
of  the  future  system,  pointing  to  the  sunk  costs  as  justification.  Although  legacy  system 
functionality  need  not  be  discarded,  the  new  architecture  should  be  developed  based  on 
supporting  desired  C2  processes  and  performance,  flexibility,  and  evolvability  criteria,  and  the 
architectural  strategy  and  plan  should  focus  on  adapting  legacy  functionality  into  the  new  plan, 
not  vice  versa.  If  an  architectural  strategy  is  built  around  legacy  systems  and  old  acquisition  and 
software  practices,  none  of  the  point  technologies  (HTML,  Java,  XML)  or  spiral  development 
strategies  will  achieve  the  intended  effect:  A  robust,  easy  to  use,  evolvable,  cost-effective, 
reliable  system  that  is  amenable  to  rapid  technology  insertion. 

There  are  many  obvious  barriers  to  successfully  implementing  and  deploying  an  enterprise 
system.  Business  has  typically  faced  similar  challenges.  What  enabled  business  organizations  to 
move  to  this  collaborative,  enterprise-wide,  cross-organizational  information  system  was  the 
realization  that  it  was  of  mutual  benefit  and  was  necessary  to  accomplish  the  commercial 
mission.  Collaboration  and  interoperability  were  driven  by  the  re-engineering  of  specific 
processes,  not  by  a  mandate  to  do  everything  the  same  way.  If  we  organize  our  efforts  around 
the  desired  C  scenarios  and  experimentation  with  new  ways  of  doing  business,  it  will  provide  an 
operational  grounding  and  definable  consequences  for  eliminating  these  barriers. 

4.4  Recommendations 

The  consensus  of  the  study  is  that  many  of  the  technologies  exist  which  are  needed  to  build  the 
JBI  and  to  provide  the  new  capabilities  desired  to  enhance  C2  operations.  Many  of  the  barriers  to 
moving  forward  and  leveraging  this  technology  base  are  process  or  institutional  in  nature  rather 
than  technical.  Many  of  our  recommendations  therefore  focus  on  identifying  on  how  to  speed 
technology  deployment  into  the  Air  Force.  In  the  following  sections  we  describe  changes 
recommended  to  accelerate  the  technology  transition  process  and  better  leverage  the  commercial 
and  government  research  and  development  (R&D)  investment  to  provide  new  C  capabilities. 

4.4.1  Faster  Technology  Deployment  Through  Spiral  Development 

The  Air  Force  has  elected  to  move  to  a  spiral  development  process  in  support  of  evolutionary 
acquisition  for  C  systems.  This  instruction  encompasses  all  system  acquisition  life-cycle 
activities  of  C2  systems,  existing  or  planned,  from  an  initial  idea  or  technological  opportunity 
through  fielding  and  sustainment. 

One  of  the  major  benefits  of  a  spiral  development  process  over  a  classic  waterfall  development 
process  is  that  it  does  not  presume  that  the  requirements  are  knowable  in  advance  of 
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implementation.  An  example  of  this  paradigm,  for  new  user-interactive  systems,  is  known  as  the 
IKIWISI  syndrome.  When  asked  for  their  required  screen  layout  for  a  new  decision-support 
system,  users  will  generally  say,  “I  can’t  tell  you,  but  I’ll  know  it  when  I  see  it”  (IKIWISI).  In 
such  cases,  a  concurrent  prototyping/requirements/architecture  approach  is  needed,  and  spiral 
development,  rather  than  waterfall  development,  processes  should  be  used. 

In  January  2000,  the  Air  Force  Instruction  (AFI)  63-123  required  the  use  of  spiral  development 
for  C  systems.  It  created  a  hybrid  spiral  process  that  fits  (uncomfortably)  into  the  DoD  5001 
and  5002  series  of  regulations.  Despite  the  fact  that  this  instruction  is  too  new  for  any  program 
to  have  executed  under  it,  it  is  clear  that  while  the  use  of  spiral  development  is  the  correct 
approach,  our  understanding  and  direction  today  need  some  refinement. 

We  need  to  stimulate  industry  development  of  a  standard  for  spiral  development.  The 
February  2000  Joint  Symposium  on  Spiral  Development  called  for  such  a  standard,  and 
Government  participation  would  accelerate  the  process.  By  moving  from  standardization  (a 
process  owned  and  mandated  by  the  Air  Force)  to  mandatory  compliance  with  a  flexible  standard 
the  Air  Force  can  reap  many  benefits.  Once  industry  has  created  this  standard,  AFI  63-123  can 
be  greatly  simplified,  and  discuss  only  how  to  fit  spiral  development  into  the  acquisition  process. 

The  role  of  cost  as  an  independent  variable  (CAIV)  in  spiral  development  must  be  emphasized. 
Funding  timelines  make  dynamic  reallocation  difficult.  In  this  environment  each  spiral  increment 
is  unlikely  to  receive  funding  directly  commensurate  with  the  desired  accomplishments  of  that 
increment.  After  detennining  the  desired  level  of  risk  reduction  and  functional  addition  ideal  for 
a  phase,  CAIV  processes  are  essential  to  determining  how  much  of  each  should  actually  be  done. 
Learning  how  best  to  apply  CAIV  processes  to  spiral  development  is  an  essential  task  that  should 
be  done  by  a  Government-industry  team. 

We  must  define  critical  interfaces  and  elements  of  the  user  interface  with  considerable  rigor  in 
advance.  These  are  the  portions  that  affect  other  developments  and  the  entire  training  process. 

We  must  allow  these  elements  to  evolve  slowly  and  with  a  great  deal  of  thought  to  the  impacts  to 
users  and  other  systems  and  allow  all  other  aspects  of  the  architecture  to  evolve  freely  from 
spiral  to  spiral. 

4.4.2  Move  to  Procurement  Through  Concept  of  Operations  (CONOPS) 

The  Air  Force  is  slow  to  incorporate  new  information  technologies  into  C  systems.  One  of  the 
reasons  for  the  delay  is  that  procurement  of  information  technology  (IT)  systems  proceeds 
through  the  same  requirements  process  as  for  purchasing  an  airplane  or  a  ground  vehicle.  The 
idea  of  developing  commercial  systems  by  satisfying  detailed  requirements  was  discarded  long 
ago  by  the  business  community.  Rapid  development  of  new  applications  by  commercial  industry 
is  done  on  the  basis  of  a  stated  operational  need  and  through  close  collaboration  between 
developer  and  user. 

The  Air  Force  analog  to  procurement  from  need  is  procurement  through  CONOPS.  Usually, 
suggestions  for  new  capabilities  result  in  a  CONOPS.  It  should  be  possible  to  procure  a  system 
to  provide  needed  capabilities  by  simply  replacing  multipage  requirements  documents  with  a 
CONOPS  document.  The  reduction  of  needs  to  requirements  is  a  process  that  frequently  results 


16  Air  Force  Instruction  63-123,  Evolutionary’  Acquisition  for  C2  Systems. 
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in  errors  than  are  reflected  in  the  final  product.  After  all,  what  is  truly  required  is  a  capability, 
not  the  satisfaction  of  a  fonnal  process. 

It  will  be  necessary  to  establish  an  evaluation  group  to  certify  that  the  operational  capabilities 
have,  indeed,  been  established.  The  group  should  be  populated  mostly  by  users  of  the  new 
system  but  should  include  technologists  and  system  developers.  The  group  must  be  a  hands-on 
user  group.  The  integrated  product  team  (IPT)  model  is  not  acceptable.  The  IPT  process  has 
become  so  bureaucratic  that  it  is  hardly  useful  in  the  modern  world  of  military  procurement. 
Membership  is  frequently  at  the  wrong  management  level.  For  the  CONOPS  procurement 
method  to  work,  the  evaluation  group  must  consist  of  people  at  the  working  level — that  is,  users 
and  software  and  computer  developers.  Such  a  radical  change  in  process  may  not  be  popular 
with  contractors,  but  the  purpose  of  the  Air  Force  acquisition  process  is  to  provide  new 
capabilities,  not  to  procure  new  “widgets.” 

A  CONOPS  can  be  a  simple  overview  of  connectivity  and  functional  nodes,  or  it  can  be  a  set  of 
detailed  descriptions  of  connections,  infonnation  flows,  activities,  interdependencies,  and 
timelines  for  a  number  of  possible  scenarios  or  conditions  from  the  perspective  of  different  user 
organizations.  These  descriptions  can  be  represented  in  simulations  that  provide  perfonnance 
and  flow  dynamics  over  time.  The  latter  version  of  CONOPS  is  the  approach  currently  taken  by 
AC2ISRC,  and  the  approach  that  will  yield  data  appropriate  for  acquisition  in  the  spiral 
development  model.  These  CONOPS  provide  a  rich  model  for  developers  and  contractors  to 
determine  performance  needs,  and  it  opens  up  the  technical  trade  space  and  technology  options 
to  provide  the  capabilities  needed  in  a  timely,  cost-effective  fashion.  The  functional  node 
representation  along  with  the  dynamic  simulation  allows  the  detection  of  successive  gaps  and 
bottlenecks  in  the  process  and  identifies  high  leverage  points  for  technology  development  and 
insertion.  This  approach  ensures  optimal,  operationally  significant  improvement  in  defined 
processes  and  is  far  more  reliable  in  ensuring  operational  capabilities  than  the  fonnal 
requirements  process. 

4.4.3  Planned  Divestiture  for  Obsolete  Systems 

Sustainment  is  a  big  bill  to  pay  and  a  significant  barrier  to  technology  transition.  During  the 
2002  Program  Objective  Memorandum,  the  MAJCOMs  identified  240  sustainment  disconnects 
and  initiatives  of  nearly  $3.5  billion  unfunded  annual.  U.S.  Air  Forces  in  Europe  and  the  Pacific 
Air  Forces  requested  a  50  percent  increase  in  O&M  across  the  Five-Year  Defense  Plan.  Increase 
in  capability,  historically,  is  not  programmed  with  proportional  increase  in  support  infrastructure. 
Much  of  this  bill  is  the  essential  infrastructure  and  training  needed  to  underpin  our  C2ISR 
capabilities.  Facing  these  huge  bills,  the  MAJCOMs  are  often  unwilling  to  add  new  capabilities, 
which  only  adds  to  their  sustainment  burden.  Hence,  many  outstanding  technologies,  and  the 
military  capabilities  that  they  enable,  remain  in  the  labs  and  in  the  industries  where  they  were 
developed. 

In  today’s  budgetary  environment,  the  only  way  to  afford  new  capability  is  to  divest  of  old 
capability.  Given  that  the  Air  Force  cannot  pay  for  everything  it  wants,  difficult  decisions  need 
to  be  made  as  to  which  capabilities  are  truly  needed  and  which  are  not.  Something  good 
generally  must  be  given  up  to  pay  for  fielding  something  better.  These  decisions  are  very  tough 
to  make  and  require  involvement  of  the  most  senior  leadership  in  the  Air  Force  and  DoD.  The 
Air  Force  needs  to  consider  the  current  investment  in  C  and  ISR — is  it  sufficient  to  carry  us  into 
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the  warfare  of  the  Information  Age?  This  assessment  should  focus  on  overall  capability,  not  on 
individual  programs.  A  process  needs  to  be  developed  in  the  Air  Force  for  identifying  legacy 
systems  that  are  beyond  their  effective  lifespan. 

4.4.4  Timely  Application  of  COTS 

In  the  C  information  technology  environment,  the  deployed  capability  is  usually  3  to  7  years 
behind  the  state-of-the-art  technology  in  the  commercial  world.  The  commercial  IT  engine  tends 
to  turn  over  technology  in  8-  to  15-month  cycles  due  to  upgrades  in  software/hardware  and 
changes  to  respond  to  market  forces.  The  result  to  the  military  is  that  much  of  the  COTS 
technology  being  deployed  in  C2  systems  is  already  outdated  by  the  time  it  is  delivered  to  the 
operational  warfighter.  There  are  multiple  reasons  why  this  problem  exists: 

•  First,  many  IT  acquisitions  have  used  a  waterfall  development  cycle  that  freezes  the  COTS  early 
in  the  development  cycle  with  no  plan  to  upgrade  as  new  releases  are  announced.  The  acquisition 
process  has  allowed  contractors  to  modify  COTS  to  better  fit  operational  requirements,  with  the 
result  that  the  capability  is  no  longer  COTS  and  costly  upgrades  are  needed  to  add  new 
capabilities  that  otherwise  would  have  been  available  in  the  next-generation  COTS  product. 

•  There  are  no  general  plans  to  accommodate  new  releases  and  upgrades  during  development,  as 
funds  set  aside  to  do  this  have  proved  difficult  to  defend. 

•  The  COTS  developer  is  usually  forced  to  work  through  a  prime  integration  contractor.  The  result 
of  this  is  that  the  COTS  developer  is  often  not  integrally  involved  in  plans  for  future 
development,  and  the  integration  contractor  is  not  always  aware  of  what  next-generation  COTS 
products  will  be  able  to  accomplish. 

To  avoid  these  problems  in  the  future,  the  Air  Force  should  plan  to  build  C  systems,  where 
possible,  using  unmodified  COTS  products.  Enterprise  licenses  should  be  negotiated  for  core 
COTS  products  to  facilitate  their  ubiquitous  use  operationally.  Using  the  built-in  development 
tools  available  in  the  current  generation  of  IT  products,  many  operational  needs  can  be  satisfied 
by  distributing  freeware — customized  scripted  programs  that  run  on  COTS  applications. 

4.4.5  Facilitate  Science  and  Technology  (S&T)  Transition 

The  task  of  transitioning  technology  developed  in  AFRL  and  Battlelabs  has  been  a  primary  area 
of  concern  and  a  constant  source  of  frustration.  While  technology  development  always  involves 
the  failure  of  some  efforts  due  to  technological  limitations,  the  process  of  incorporating  into  Air 
Force  C2  systems  those  pieces  that  do  succeed  has,  for  the  most  part,  also  failed.  The  sources  of 
this  failure  range  from  poor  communication  to  long,  bureaucratic  processes  that  result  in 
technology  obsolescence  before  new  capabilities  can  even  be  deployed.  While  much  of  the  Air 
Force’s  C2  needs  can  be  addressed  by  leveraging  commercial  technology,  there  are  areas  where 
focused  investment  is  needed  to  develop  capabilities  where  no  commercial  market  analog  exists 
(see  Figure  4-1).  It  is  essential  that  the  Air  Force  and  DoD’s  investments  in  these  areas  can 
rapidly  transition  into  operational  use  to  augment  the  capabilities  available  from  COTS 
information  systems. 

The  primary  barrier  to  technology  transition  from  the  laboratories  in  the  IT  fields  was  perceived 
as  being  due  to  a  lack  of  communication  between  technology  developers  and  the  actual  users. 
This  communication  is  essential  early  on  in  the  development  process  to  connect  the  technology 
push  to  the  operational  user  pull.  With  the  current  Air  Force  R&D  process,  the  communication 
to  the  laboratory  of  the  C2  capability  needs  and  requirements  is  through  multivolume  documents 
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published  by  the  AC2ISRC.  This  process  is  a  poor  substitution  for  establishing  communication 
between  the  technologist  and  the  operator  during  development.  Without  this  connection,  the 
technology  developers  are  frustrated  by  not  knowing  what  the  users  want,  and  the  users  are 
frustrated  that  the  technologists  cannot  meet  their  needs.  Moreover,  the  time  spent  by  the 
technologists  to  track  down  what  was  meant  by  a  specific  capability  need  and  how  complex  the 
need  truly  is  detracts  from  the  productive  time  spent  on  the  development  effort. 

The  consolidation  of  C  requirements  by  AC2ISRC  is  useful  endeavor  that  can  result  in  one-stop 
shopping  to  match  a  technology  with  a  need.  But  often  the  result  is  the  direct  isolation  of 
technologists  from  users  and  their  environment,  causing  confusion,  and  a  lack  of  user  context. 
There  needs  to  be  a  better  teaming  approach  among  the  Air  Force  laboratories,  Battlelabs, 
AC2ISRC,  and  the  user  community  to  better  facilitate  overall  communication.  Improving  this 
communication  can  lead  to  more  effective  transitions  of  technology. 

Where  a  good  teaming  relationship  has  existed  between  the  laboratory  and  the  user  community, 
technology  transition  has  proved  to  be  very  successful.  Without  this  relationship,  the  technology 
transition  record  through  the  acquisition  program  has  proved  abysmal.  For  example,  the 
Intelligence  Division  at  AFRL/IF  has  been  very  successful  over  the  past  three  decades  by 
working  very  closely  with  the  intelligence  users  to  develop  the  requirements  together  and 
explore  the  space  of  what  is  possible  and  by  developing  these  systems  for  direct  insertion  to  the 
field.  The  current  Broadsword  effort  at  AFRL/IF  is  an  example  of  spiral  development  where  a 
small  team  of  developers  and  users  consistently  worked  together  to  produce  a  technology 
product  that  is  fielded,  meets  users’  capability  needs,  and  is  constantly  improved  with  user 
involvement.  Another  example  of  a  transition  success  has  been  the  technical  relationship 
established  between  AFRL/IF  and  AMC.  While  embarking  on  Mobility  2000,  a  major  initiative 
to  improve  its  C  and  business  practices,  AMC  understood  that  technology  could  not  solve,  but 
could  help  improve,  those  processes  to  better  match  the  much  more  efficient  processes  found  in 
the  commercial  airline  industry.  AMC  and  AFRL/IF  signed  a  Memorandum  of  Agreement  that 
established  an  “information  technology  pipeline”  between  IF  and  AMC.  IF  would  constantly 
look  at  its  tech  base,  consisting  of  GOTS  development  via  DARPA  and  COTS  tools  to  look  for 
new  solutions  to  the  capability  needs  of  the  initiative.  This  resulted  in  the  establishment  of  an 
AMC/IF  Skunk  Works  concept  and  facility,  where  new,  innovative  solutions  could  be  tried  in  a 
realistic  environment.  This  type  of  “honest  broker”  relationship  has  resulted  in  several  ongoing 
transitions  of  information  technology  to  operational  AMC  systems,  with  spirals  taking  place  both 
during  and  out  of  cycle  with  JEFX. 

The  majority  of  information  technology  funds  managed  by  AFRL/IF  are  provided  by  DARPA  as, 
over  the  years,  the  Air  Force’s  S&T  investment  in  this  area  has  shrunk  drastically.  AFRL/IF  has 
taken  a  portion  of  the  dwindling  Air  Force  S&T  6.3a  funds  to  attempt  to  facilitate  the  transition 
process.  This  facilitation  occurs  by  forming  critical  experiments  and  Technology  Integration 
Experiments  (TIEs),  which  involve  an  Air  Force  user  and  a  specific  Air  Force  user  need. 

Because  these  are  experiments,  some  of  these  TIEs  fail  or  are  dead-end  engineering,  while  others 
are  used  as  an  initial  technology  transition  spiral.  The  result  so  far  is  that  several  have 
transitioned  to  users,  while  others  promote  subsequent  TIEs,  therefore  becoming  subsequent 
spirals,  and  others  have  developed  into  entirely  new  technology  programs. 
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4.4.6  Leverage  New  Sources  of  Technology  for  the  Air  Force 

The  Air  Force’s  future  will  require  the  ability  to  rapidly  respond  to  a  changing  and  uncertain 
future  mission.  The  current  large-scale  vertically  integrated  monolithic  integration  process  is 
based  on  a  single  prime  contractor  and  a  rigid  requirement  process.  The  Air  Force’s  ability  to 
obtain  access  to  innovation  and  emerging  technologies  that  ensure  a  competitive  advantage  are 
severely  restricted  by  this  rigid  acquisition  model.  Industry  has  evolved  to  a  horizontally 
integrated,  segmented  acquisition  model  based  on  the  following  three  principles:  (1)  a  simple 
underlying  architectural  model  based  on  standards,  (2)  an  acquisition  strategy  based  on 
component  development  that  heavily  leverages  software  reuse  and  existing  product  services  due 
to  the  premium  for  access  to  talent  and  pressure  to  reduce  time  to  market  requires  an  acquisition 
strategy,  (3)  a  business  model  that  encourages  and  rewards  competition,  sometimes  competing 
for  the  same  market  (in  the  case  of  the  Air  Force,  the  same  mission  need).  These  principles  are 
now  transforming  the  global  economy. 

The  transfonnation  occurring  in  the  global  economy  from  a  highly  structured  sequential 
investment  strategy  to  the  very  flexible,  dynamic,  rapid  time-to-market  new  economy  model 
places  great  emphasis  on  rapid  product  insertion  into  the  marketplace.  This  new  economy  model 
places  importance  on  infonnation-based  business  processes  and  how  these  processes  guide 
investment  and  innovation.  The  Air  Force  can  exploit  a  parallel  strategy  using  the  spiral 
development  process  to  guide  the  rapid  development  of  new  technical  capabilities  into  the 
operational  environment  by  following  management  processes  similar  to  the  new  economy  model. 

As  the  Air  Force  moves  toward  the  new  economy  model  in  spiral  development,  it  will  need  to 
focus  on  how  resources  are  invested  by  leveraging  the  most  innovative  components  of  industry, 
DARPA,  university  consortia,  the  Air  Force,  allies,  and  joint-Service  laboratories  and  Battlelabs. 
Also,  one  of  the  most  overlooked  sources  of  technology  innovation  is  the  Air  Force’s  own 
workforce.  Modern  information  products  are  becoming  more  sophisticated  and  allow 
operator/users  to  “program”  these  applications  using  customized  scripts  to  perform  complicated, 
special-purpose  information  management  tasks.  With  the  pressures  being  placed  on  industry  to 
produce  better  products  more  rapidly  and  with  fewer  engineering  personnel,  this  trend  can  be 
expected  to  continue.  This  predicted  transition  is  analogous  to  the  change  in  the  telephone 
system  where  technology  had  to  be  introduced  to  replace  operator-connected  calls  with 
automatic  dialing.  Without  this  technology  change,  the  prediction  was  that  every  person  in  the 
United  States  would  need  to  become  a  telephone  operator  for  the  telephone  system  to  run. 
Without  the  technology  to  provide  user-friendly  customization  of  complex  software  applications, 
a  similar  prediction  would  be  that  every  person  in  the  United  States  would  need  to  become  a 
software  programmer  for  the  e-commerce  revolution  to  continue. 
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Figure  4-2.  New  Sources  of  Technology 


The  current  acquisition  process  is  geared  toward  large-scale  procurements  through  a  prime 
integration  contractor  familiar  with  the  Air  Force’s  legacy  C2ISR  systems.  While,  for  large  scale 
systems,  this  approach  has  proved  necessary,  the  Air  Force  needs  to  reach  out  to  alternative 
technology  sources  to  achieve  the  benefits  of  the  flexible,  dynamic,  rapid-time-to-market  new 
economy  model  in  the  next  generation  of  C  ISR  systems.  The  technology  sources  we  suggest  to 
be  better  leveraged  are  shown  in  Figure  4-2. 

4. 4. 6.1  Small  Business  Technology  Sources 

Much  of  the  information  revolution  is  being  fueled  by  small  businesses  and  e-commerce  new 
starts.  These  are  not  ordinary  defense  contractors.  The  Air  Force  can  outreach  to  these  small 
innovative  industries  through  better  use  of  the  Small  Business  Innovative  Research  (SBIR) 
program.  Congress  provided  this  means  to  gain  access  to  these  small  industries  with  funding 
already  set  aside  within  the  Air  Force  budget  (6.5)  for  R&D.  The  SBIR  program  is  conducted  in 
three  phases.  The  first  phase  provides  an  initial  assessment  of  the  technology,  the  second  phase 
concludes  with  a  limited  demonstration  of  technology  feasibility  and  maturity,  and  the  third 
phase  transitions  technology  into  commercial  use  or  into  Federally  funded  R&D. 

In  creating  the  SBIR  program,  Congress  created  a  means  for  the  Air  Force  to  focus  an 
investment  in  innovative  technology  by  providing  resources  independent  of  research, 
development,  and  acquisition  program  funding.  Congress’s  approach  was  to  give  an  incentive 
for  small  business’  access  to  Government  funding;  by  setting  aside  two  and  a  half  percent  of 
development  funding  to  the  SBIR  program.  In  C2,  these  SBIR  set-aside  funds  are  a  significant 
R&D  investment  in  comparison  with  the  AFRL/IF  discretionary  Exploratory  and  Advanced 
Development  funding,  which  has  been  declining  in  the  area  of  IT. 

The  current  management  process  for  C  SBIR  does  not  follow  a  central  strategy  coordinated  with 
the  AC2ISRC  vision.  The  SBIR  topics  are  nominated  by  AFRL  and  the  acquisition  program 
offices  (Program  Executive  Offices)  and  the  Designated  Acquisition  Commanders.  This  chaotic 
approach  leads  to  few  technology  transitions  from  the  SBIR  investment  into  operational 
capabilities.  Increased  focus  and  technology  transition  would  result  from  investing  the  C2 
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component  of  the  SBIR  funds  (those  C  programs  taxed)  based  on  a  central  strategy  developed 
and  managed  by  the  AC2ISRC.  The  execution  of  these  SBIR  funds  should  be  managed  by 
AFRL.  This  strategy  could  be  used,  for  example,  to  give  small  business  an  incentive  to  develop 
and  demonstrate  technologies  for  the  JBI. 

If  the  AC2ISRC  were  to  develop  and  operate  a  leading-edge  experimental  testbed  (for  example, 
CAOC-X),  a  large  number  of  innovative  concepts  (arising  from  large  aerospace  industry,  Service 
laboratories,  and  SBIR)  could  be  evaluated.  Those  demonstrating  utility  to  AC2ISRC  and  that 
were  sufficiently  mature  would  rapidly  move  to  an  operational  prototype  for  testing  and 
evaluation  by  the  users.  A  budget  should  be  set  aside  for  Phase  III  transitions  to  rapidly  occur 
from  successful  SBIR  development  efforts. 

4.4. 6.2  DARPA  as  a  Technology  Development  Partner 

DARPA  is  making  a  significantly  larger  investment  in  IT  than  the  Air  Force  is.  This  could  be 
better  leveraged  within  the  Air  Force  by  re-establishing  the  long-standing  relationship  that  the 
Air  Force  had  previously  with  DARPA.  Up  until  the  past  10  years,  the  Air  Force  agenda 
dominated  the  investment  strategy  at  DARPA.  The  Air  Force  not  only  provided  90  percent  of 
the  military  workforce  but  also  sent  only  its  most  competent  and  trusted  officers  to  DARPA. 
Because  DARPA  possesses  both  a  culture  of  innovation  and  a  budget  to  support  innovative 
solutions  the  rebuilding  of  this  close  relationship  will  be  critical  for  the  JBI. 

The  Air  Force  Technology  Executive  Officer  should  assign  adequate  quality  personnel  to 
DARPA  to  ensure  that  the  Air  Force’s  JBI  objectives  are  met.  DARPA  is  not  currently  part  of 
the  JBI  process  and  yet  the  SAB  1998  Summer  Study  proposing  the  JBI  was  founded  mostly  on 
DARPA  technologies.  The  AC2ISRC  should  lead  an  effort  to  define  future  operational  concepts 
and  technology  needs  for  DARPA  to  focus  the  development  of  needed  technologies.  The 
AC2ISRC  should  additionally  ensure  that  DARPA  is  integrated  into  the  leading-edge  spiral  JBI 
experimental  evaluation  process. 

4. 4. 6. 3  University  Research 

Many  of  the  emerging  information  technologies  needed  for  the  JBI  begin  in  the  university 
system.  Air  Force  Office  of  Scientific  Research  (AFOSR)  and  AFRL  have  an  ongoing  research 
relationship  with  specific  components  of  the  university  system  for  more  generic  technology 
development.  Working  with  concepts  developed  by  the  AC2ISRC,  AFOSR,  and  AFRL  should 
encourage  investments  in  university  research  that  lead  to  new  capabilities  for  the  JBI.  AC2ISRC 
should  provide  access  to  the  leading-edge  spiral  JBI  environment  for  experimentation  and 
evaluation  of  these  emerging  capabilities. 

4.4. 6.4  Joint-Service  and  Allies  ’  Laboratories 

A  major  source  of  new  technology  and  concepts  for  interoperability  is  other  Service  labs  and  our 
allies’  laboratories.  One  major  challenge  facing  the  JBI  is  the  integration  of  other  Services  and 
our  allies  into  C  operations.  The  leading-edge  spiral  JBI  provides  both  the  platform  for  other 
Service  technology  demonstration,  and  it  exploits  the  technology  and  policy  issues  of  combined 
C  operations.  AC2ISRC  should  develop  processes  and  procedures  to  guide  the  development  of 
technology  that  enables  combined  C2  operations  within  the  leading-edge  spiral  JBI.  The  JBI 
testbed  should  be  expanded  to  allow  joint-Service  laboratories  and  our  allies  to  participate  in 
development  of  the  JBI. 
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4. 4. 6. 5  Air  Force  Operators  as  Technology  Developers 

Perhaps  the  most  important  source  of  innovation  for  next-generation  C“ISR  systems  is  the  “blue 
suit”  officers  and  enlisted  personnel  in  the  Air  Force.  These  people  are  experienced  in  the  Air 
Force’s  mission  and  technology  needs  and  represent  one  of  the  most  valuable  sources  of  mission- 
specific  solutions.  Because  of  frustration  with  the  current  acquisition  process,  many  users  are 
developing  workarounds  or  patches  using  COTS  tools  to  improve  their  daily  productivity.  Many 
of  these  “temporary”  fixes  have  subsequently  proved  to  perfonn  better  than  their  core  system 
counterparts  once  they  have  been  fielded.  This  occurred  because  of  the  following  two  essential 
ingredients:  (1)  in  many  cases,  the  operators  themselves  best  understood  the  existing  C2  process 
they  were  following  and  how  to  improve  it;  (2)  the  COTS  information  tools  used  to  develop  the 
improved  process  included  sophisticated  customization  capabilities  allowing  an  essentially  new 
software  to  be  developed  using  scripts  rather  than  raw  software.  Since  this  trend  can  be  expected 
to  continue,  the  Air  Force  should  establish  a  process  whereby  these  operator-developed  systems 
can  be  adopted  into  the  core  C“ISR  systems.  This  will  require  the  development  of  standards  for 
documenting  and  sustaining  these  new  applications.  Since  these  have  been  developed  using 
commonly  used  COTS  products,  by  operators,  for  use  by  operators,  the  sustainment  cost  will 
likely  be  significantly  lower  than  for  custom-developed  applications.  For  example,  training  to 
use  a  new  application  for  an  operator  already  familiar  with  the  core  software  product  and  with 
the  C2  process  being  followed  would  likely  be  no  harder  than  learning  to  use  a  new  Web 
browser. 

The  Air  Force,  like  other  governmental  organizations,  faces  the  loss  of  quality  people  with 
information  skills  to  opportunities  outside  government.  The  Air  Force  should  consider  creating 
an  adjunct  to  AC2ISRC  that  gives  hand-selected  individuals  opportunities  to  develop,  evaluate 
and  deploy  rapid  advances  in  the  technologies  needed  for  the  JBI.  The  Air  Force  should 
implement  a  career  rewards  program  for  the  most  successful  individuals  to  ensure  that  they 
continue  their  Air  Force  careers. 
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Appendix  4A 
Technology  Panel  Charter 

1 .  Identify  the  technologies  that  can  enhance  present  and  future  C  systems  with  a  near-tenn 
emphasis  on  the  following  capabilities: 

•  Network-centric  operations 

•  Interoperability  within  the  Air  Force,  with  the  other  Services,  and  between  legacy  stovepiped 
systems 

•  Timely  and  effective  communication 

2.  Provide  support  to  the  Concept  and  System  Definition  and  Interoperability  panels  on 
technologies  that  are: 

•  Available  for  the  2005  system 

•  In  development  and  which  might  bridge  to  providing  JBI  capabilities 

•  Needed  before  the  JBI  can  be  implemented 

3.  Provide  recommendations  to  the  Concept  and  System  Definition  and  Interoperability  panels 
on  technologies  that  could  be  available  to  field  in  near-term  operational  demonstrations  (for 
example,  Expeditionary  Force  Experiment  2002). 

4.  Work  with  the  Acquisition  Panel  to  investigate  methods  for  speeding  transition  of  technology 
from  development,  experimentation,  and  operational  demonstrations  to  fielded  implementation. 

5.  Investigate  COTS  technologies  that  can  be  leveraged  with  an  emphasis  on  near-tenn 
capabilities  that  could  be  fielded  to  evolve  the  JBI. 

6.  Technology  areas  to  be  investigated  will  include  (but  are  not  limited  to) 

•  System  and  software  development  processes  and  tools 

•  Planning  and  decision  making  aids,  models,  and  tools 

•  Communications 

•  Data  links  and  message  protocols 

•  Network  architectures 

•  Multi-level  security 

•  Data  lusion,  management,  and  presentation 

•  Geolocation  and  targeting 
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Appendix  4B 

Technology  Panel  Membership 


Dr.  Alison  K.  Brown,  Chair 
President 

NAVSYS  Coiporation 

Dr.  Thomas  A.  Brackey,  Deputy  Chair 
Executive  Director,  Technical  Operations 
Hughes  Space  and  Communications  Company 

Dr.  Duane  A.  Adams 
Vice  Provost  for  Research 
Carnegie  Mellon  University 

Mr.  Timothy  M.  Bonds 
Analyst 

The  RAND  Coiporation 

Mr.  John  N.  Entzminger 
Private  Consultant 

Dr.  Gene  H.  McCall 
Chief  Scientist 
AFSPC 

Prof.  Alan  S.  Willsky 

Department  of  Electrical  Engineering  and  Computer  Science 
Massachusetts  Institute  of  Technology 

Maj  Kenneth  S.  Kreit 

Program  Manager,  Large  Aperture  Spacecraft 
National  Reconnaissance  Office 

Advisors:  Dr.  Kevin  B.  Kreitman,  Aerospace  Corporation 

Mr.  Richard  Metzger,  AFRL/IF 
Mr.  Jay  Scarano,  MITRE  Corporation 
Maj  Michael  J.  Estes,  C2ISR  Center 
Maj  William  Richard,  SAF/AQII 

Executive  Officer:  Maj  Timothy  P.  Nickerson,  AMC/XPX 
Technical  Writer:  Maj  Joseph  E.  Brouillard,  USAFA/IG 
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Appendix  4C 

Defense  Information  Infrastructure  Common  Operating  Environment 

(DII  COE) 


1.1  Introduction 

The  Air  Force  is  becoming  increasingly  dependent  on  using  commercial  software  in  major 
defense  systems.  Examples  include  the  Airborne  Warning  and  Control  System  and  the  Theater 
Battle  Management  Core  System  (TBMCS).  The  major  benefit  of  using  commercial-off-the- 
shelf  (COTS)  software  is  that  the  Air  Force  can  leverage  the  huge  investment  being  made  by  the 
private  sector  to  develop  software  that  is  very  similar  if  not  identical  to  that  needed  by  the  Air 
Force.  Furthermore,  exploiting  commercial  software  lets  the  Air  Force  stay  at  the  leading  edge 
of  what  is  available.  The  days  when  the  Air  Force  led  the  commercial  sector  in  developing 
software-intensive  systems  are  gone  and  not  likely  to  return. 

There  are  a  series  of  obstacles  which  must  be  overcome  in  order  to  take  advantage  of  COTS 
software.  The  biggest  obstacle  to  successful  commercial  technology  incorporation  is  inflexible 
requirements.  Effective  use  of  COTS  products  demands  flexible  requirements  from  the  outset 
and  a  trade-off  process  that  extends  throughout  the  entire  engineering,  manufacturing,  design, 
testing  and  fielding  process.  A  second  obstacle  is  that  commercial  computing  and 
communication  technology  is  a  “moving  target”  that  must  be  dealt  with  continuously  throughout 
the  life-cycle  of  the  system.  A  major  system,  composed  of  many  products  developed  by  a 
number  of  different  vendors,  can  be  very  difficult  to  maintain  by  the  traditional  method  of 
periodic  releases,  say  every  18  months.  This  is  because  the  commercial  products  are  on 
independent  development  cycles,  many  much  shorter  than  the  periodic  release  cycle.  The 
periodic  releases  may  introduce  new  functionality  as  well  as  fix  bugs.  A  fixed  18  month  release 
cycle  means  than  much  of  the  software  in  the  system  is  obsolete  for  the  bulk  of  the  time  it  is  in 
production.  This  can  result  in  frustration  for  the  users  who  want  to  take  advantage  of  newer 
technology,  and  can  be  a  burden  for  developers  who  must  continue  to  build  on  an  old  technology 
base.  This  must  be  balanced  against  the  risk  of  introducing  upgrades  and  new  products,  that  may 
introduce  software  errors  or  perturbations  in  the  testing  environment. 

Commercial  technology  that  we  wish  to  exploit  comes  in  many  forms,  including  system 
software,  applications  software,  appliance  devices  such  as  personal  digital  assistants,  and 
development  tools  such  as  scripting  languages.  Complementing  the  commercial  products  are 
research  products  from  organizations  such  as  the  Defense  Advanced  Research  Projects  Agency 
(DARPA),  Air  Force  Research  Laboratory  (AFRL),  ACTDs,  Battle  Labs  and  locally-developed 
software  products  which  meet  the  needs  of  particular  user  communities.  The  challenge  is  to  find 
a  process  that  encourages  and  facilitates  the  use  of  this  expanded  technology  base  while 
preserving  the  integrity  of  the  systems  that  must  remain  operational  during  the  transition. 

This  document  discusses  one  particular  part  of  the  infrastructure,  the  Defense  Infonnation 
Infrastructure  Common  Operating  Environment,  better  known  as  the  DII  COE. 
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1.2  What  is  DII  COE? 


At  the  highest  level  of  description,  the  DII  COE  is  a  creation  of  the  Department  of  Defense 
(DoD)  designed  to: 

•  Facilitate  joint  system  interoperability 

•  Improve  functionality  for  the  warfighter 

•  Realize  savings  in  system  life-cycle  costs 

At  another  level  DII  COE  is: 

•  A  reference  implementation  of  the  DoD  Joint  Technical  Architecture  (JTA) 

•  A  software  infrastructure 

•  An  approach  to  facilitate  integration 

•  An  approach  to  improve  software  engineering  discipline 

In  terms  of  components,  DII  COE  is  composed  of: 

•  Operating  system  services  (Unix,  NT)  and  windowing  (X,  Motif,  NT) 

•  Infrastructure  services  (printing,  Web  servers,  communications,  management  services,  toolkits, 
etc.) 

•  Database  schemas  and  metadata  standards 

•  Common  support  applications  (office  automation,  message  processing,  etc.) 

•  Standard  applications  programming  interfaces 

Applications  run  on  top  of  DII  COE.  TBMCS  is  such  an  application. 

1.3  Why  have  a  Common  Operating  Environment  (COE)? 

You  might  wonder  if  the  DoD  is  the  only  entity  that  has  a  COE,  and  it  clearly  is  not.  Most  major 
corporations  have  a  COE  and  a  software  development  process  for  their  internal  use.  The  main 
reason  for  having  a  COE  (and  the  tools  that  support  it)  is  to  facilitate  the  installation,  operation 
and  maintenance  of  applications.  The  DoD  COE  goes  a  step  further  than  most  organizations, 
prescribing  rules  to  ensure  that  applications  do  not  interfere  with  each  other  when  concurrently 
installed  on  the  same  piece  of  hardware,  and  supplying  installation  software  that  provides 
capability  beyond  commercial  technology. 

Vendors  of  major  computing  systems  often  provide  a  similar  environment  and  support  tools.  For 
example,  most  PC  users  are  familiar  with  a  Microsoft  operating  system  (Windows  95,  98,  or  NT) 
and  many  of  the  applications  that  one  might  choose  to  install  (for  example,  Norton  anti  virus 
software  or  the  Netscape  browser)  come  with  the  tools  necessary  to  install  them  on  a  Microsoft 
platform.  The  same  is  true  for  applications  on  an  Apple,  IBM,  Dell,  or  Sun  platform.  However, 
the  environments  provided  by  Microsoft,  Apple,  and  Sun  are  different.  So  are  their  tools,  and 
one  cannot  depend  on  all  third  party  software  systems  (for  example,  Norton  anti  virus  software) 
to  follow  any  particular  convention  for  installing  and  de-installing  their  applications.  Nor  can 
one  assume  that  the  installation  of  a  new  application  or  a  product  upgrade  won’t  break  some 
other  application.  It  is  a  user-beware  environment  today. 
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The  DII  COE  is  built  primarily  using  commercially  available  software  systems.  The  current 
version  is  typically  referred  to  as  the  COE  4.x  series.  COE  4.x  includes  Solaris  7  and  8,  Oracle 
8i,  Windows  2000,  and  many  other  features,  including  more  extensive  use  of  Java.  COE  5.x  will 
include  updates  to  the  standard  platforms  mentioned  above  and  real-time  support  such  as  the 
Lynx  Operating  System  and  real-time  CORBA  products.  Current  TBMCS,  because  it  has  been 
in  development  for  several  years,  will  be  fielded  on  COE  3.1  for  the  Navy  and  COE  3.3  for  the 
Air  Force.  COE  3.x  includes  Sun’s  Solaris  2.5.1,  Oracle’s  7. 3. 2. 3  database  and  Microsoft’s 
NT4,  among  others.  COE  3.x  will  be  in  the  field  for  several  years  to  support  TBMCS 
operations. 

One  of  the  key  concepts  in  the  DII  COE  is  the  Integration  and  Run  Time  Specification  (I&RTS). 
This  specifies  the  run  time  environment  and  informs  application  developers  of  their 
responsibilities  if  they  are  building  applications  to  run  on  the  COE.  The  focus  is  on  allowing  run¬ 
time  integration.  There  is  an  8  level  hierarchy  that  describes  various  levels  of  compliance. 

Level  5  compliance  is  the  near-term  goal  for  most  applications.  It  is  commonly  described  as 
“peaceful  coexistence”,  meaning  that  when  an  application  is  loaded  on  a  platform  or  un-installed, 
it  will  not  adversely  affect  any  other  application  on  the  same  platfonn. 

The  above  description  is  only  meant  to  indicate  the  general  direction  of  the  DII  COE  evolution, 
not  a  complete  description  by  any  means.  This  is  clearly  a  significant  undertaking  for  the  DoD. 
Counting  the  COTS  and  government-off-the-shelf  (GOTS)  software  in  DII  COE,  there  are 
reportedly  over  1  billion  lines  of  code.  While  most  of  this  code  is  in  the  fonn  of  major 
commercial  components  (Solaris,  NT,  Oracle,  etc.),  it  also  represents  a  significant  amount  of 
GOTS  software  (20  million  lines  for  the  Common  Operational  Picture  [COP]  alone)  and  there  is 
replicated  functionality  with  what  commercial  organizations  would  normally  supply  with  their 
products  (for  example,  the  kernel  includes  a  common  desktop  and  software  installation  tools).  It 
is  Defense  Information  Systems  Agency’s  (DISA’s)  stated  intention  to  get  out  of  the  kernel 
business  and  rely  on  commercial  products  as  much  as  practical.  We  believe  this  is  a  good  move. 
However,  achieving  and  maintaining  parity  among  the  various  computing  platforms  will  remain 
a  challenge. 

1.4  TBMCS  and  DII  COE 

TBMCS  is  a  major  application  that  uses  DII  COE.  TBMCS  was  one  of  the  first  to  use  the  COE, 
and  as  such  experienced  many  of  the  DII  COE’s  growing  pains.  This  points  out  the  problem  of 
implementing  policy  before  the  execution  plan  and  technology  are  ready.  It  has  been  estimated 
that  having  to  comply  with  DII  COE  cost  the  TBMCS  program  about  $9  million.  We  are  not 
able  to  establish  that  this  cost  is  due  to  DII  COE  alone,  or  whether  some  of  the  costs  are  related 
to  other  factors.  These  could  include  having  to  segment  legacy  applications,  modifying 
applications  to  integrate  upgrades  for  commercial  products  that  are  part  of  the  COE,  and 
imposing  good  software  engineering  practices. 

TBMCS  will  be  used  by  both  the  Air  Force  and  the  Navy,  and  today  these  Services  operate  on 
different  hardware  bases  (the  Air  Force  on  Sun  hardware  and  the  Navy  on  HP  hardware).  There 
is  a  portability  issue,  but  at  this  time  we  do  not  know  the  extent  of  this  as  a  problem. 

DII  COE  is  on  an  18-24  month  cycle  for  introducing  major  releases.  The  release  cycle  is 
managed  by  an  Architecture  Oversight  Group  and  a  Configuration  Review  and  Control  Board 
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that  takes  into  account  the  development  and  fielding  schedules  of  the  major  command  and 
control  (C2)  systems.  The  commercial  products  that  will  be  used  to  implement  the  kernel, 
infrastructure  services  and  common  support  applications  are  identified,  baselined,  and  published. 
Programs  then  decide  if  they  will  use  the  new  release  as  a  foundation  for  their  system 
development,  or  if  they  will  retain  an  older  version  of  DII  COE  for  existing  systems  such  as 
TBMCS.  Once  development  has  started,  the  program  office  must  consciously  decide  whether  to 
accept  any  changes  to  the  baseline. 

Establishing  a  new  baseline  is  just  the  beginning.  TBMCS  must  then  be  integrated  in  the  new 
system,  tested,  validated  and  released  to  the  field.  It  is  likely  that  some  of  the  commercial 
components  will  be  2  to  3  years  old  before  the  user  ever  sees  the  software.  During  that  time 
there  may  have  been  one  or  more  releases  of  the  commercial  software.  This  issue  needs  to  be 
addressed — independent  of  DII  COE. 

There  has  been  concern  about  the  time  lag  between  the  introduction  of  commercial  software  and 
the  inclusion  as  a  COE  component.  For  upgrades  to  software  already  in  the  COE,  there  is  a 
relatively  short  process,  typically  measured  in  weeks.  For  new  products,  there  can  be  a  very 
lengthy  process  that  can  take  months  or  even  years.  It  is  possible  to  treat  a  product  that  should 
eventually  be  integrated  into  the  COE  as  a  mission  application,  thus  simplifying  the  compliance 
process.  This  concept  is  described  later  in  the  document. 

Even  when  new  software  shows  up  in  the  COE,  it  may  not  be  used  by  the  TBMCS  development 
community.  Risk  analysis  is  done  to  determine  if  the  benefits  of  introducing  a  change  to  the 
baseline  is  warranted.  The  further  along  in  the  development  and  test  cycle,  the  lower  the 
probability  that  any  given  upgrade  will  be  accepted,  further  reducing  flexibility  and  causing  the 
Air  Force  to  fall  even  further  behind  the  COTS  world. 

1.5  An  Assessment  of  DII  COE 
1.5.1  Standards  vs.  Standardization 

Standards  are  most  effective  when  they  formalize  a  set  of  rules  or  protocols  that  make  sense  and 
are  necessary  to  perform  a  given  function.  In  the  case  of  the  Internet,  the  Transmission  Control 
Protocol/Intemet  Protocol  protocols  allow  communication  between  computers  that  are  made  by 
different  manufacturers,  run  different  operating  systems  and  may  even  be  on  different  networks. 
These  standards  are  simple  and  in  widespread  use.  Other  standards  related  to  this  study  include 
Extensible  Markup  Language  (XML),  hypertext  markup  language,  CORBA,  etc. 

Standardization,  on  the  other  hand,  is  a  process  that  may  mandate  detailed  compliance  with  a  set 
of  processes  or  rules.  It  some  cases  the  use  of  standards  alone  is  inadequate,  and  standardization 
is  necessary.  The  developer  of  a  computer  system  may  want  to  ensure  that  subsystem  developers 
comply  with  a  common  look  and  feel,  follow  standard  documentation  processes  and  use  a 
common  set  of  development  and  installation  tools.  Standardization  often  imposes  a  greater 
burden  (in  both  time  and  cost)  on  those  who  must  follow  the  standardization  processes.  The 
benefits  of  standardization  must  be  examined  in  terms  of  their  system  costs. 

The  current  DII  COE  process  is  viewed  as  requiring  excessive  standardization.  Use  of  DII  COE 
is  mandated  for  all  command  and  control,  intelligence,  surveillance,  and  reconnaissance  systems. 
Those  wishing  to  deviate  from  the  process  must  request  a  waiver.  For  DII  COE  component 
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vendors,  not  only  must  the  developer  adhere  to  the  design  standards  (segmentation,  etc.),  but 
there  is  a  complex  design  review  and  compliance  testing  process  that  involves  final  approval 
from  DISA.  To  mitigate  the  schedule  risk  associated  with  introducing  a  component  into  the 
COE,  users  are  encouraged  to  initially  segment  and  use  the  software  as  a  Mission  Application. 
This  allows  the  users  access  to  the  application  while  the  acquisition  community  executes  the 
process  of  turning  the  software  into  a  component.  The  distinction  between  COE  components  and 
Mission  Applications  is  significant  to  developers,  and  is  briefly  described  below. 

Both  Mission  Applications  and  COE  components  require  that  the  software  be  segmented  and 
compliance  tested.  Segmentation  is  the  engineering  activity  that  makes  the  software  available 
for  integration.  The  I&RTS  rules  must  be  followed  to  ensure  that  the  software  will  behave 
properly  when  installed  on  an  end-user  platform.  Compliance  testing  verifies  that  the  software 
has  been  segmented  correctly — that  it  installs,  de-installs,  and  can  be  started  from  the  desktop. 
For  a  mission  application,  this  is  all  that  is  required  for  DII  COE  compliance. 

Software  that  will  become  a  DII  COE  component  has  additional  requirements  that  must  be  met. 

A  formal  requirements  analysis  and  design  review  must  be  performed  on  the  software.  The 
formal  requirements  analysis  results  in  the  generation  of  a  requirements  traceability  matrix.  This 
allows  developers  to  determine,  at  a  gross  level,  which  product  will  best  meet  their  needs  from  a 
technical  perspective — particularly  important  if  there  are  multiple  products  available  in  a  given 
solution  space.  Performance  requirements  are  not  addressed,  so  the  developer  must  detennine  if 
the  product  will  be  acceptable  for  their  application.  For  technology  where  mature  standards  exist 
and  technical  requirements  are  well  defined,  this  process  does  not  take  long,  on  the  order  of  2-3 
months.  Difficulties  arise  and  timelines  are  longer  when  attempting  to  componentize  products 
related  to  new  or  immature  technology.  In  this  case,  there  may  not  be  relevant  standards,  and 
technical  requirements  may  not  exist.  Then,  the  technical  requirements  must  be  developed 
before  the  requirements  analysis  can  be  done.  This  can  be  an  arduous  task  taking  months  or 
years  to  resolve. 

1.5.2  Interoperability 

One  of  the  goals  of  the  DII  COE  is  to  support  interoperability.  At  level  5  compliance  with  the 
I&RTS,  this  means  “peaceful  coexistence”;  that  is,  applications  do  not  interfere  with  each  other. 
What  we  really  want  is  “semantic  interoperability”.  This  means  that  there  is  a  shared 
understanding  of  the  meaning  of  a  concept  of  data  element,  and  hence  every  application  will 
correctly  interpret  the  data  it  obtains  from  every  other  application.  Past  efforts  to  establish 
semantic  interoperability  have  attempted  to  create  standard  data  dictionaries  and  to  mandate 
compliance  with  a  common  registry  of  terms  and  data  elements.  This  approach  can  be  made  to 
work  for  a  small  community  over  a  small  subject  area,  but  it  is  not  feasible  for  semantic 
interoperability  across  the  entire  DoD.  The  difficulty  of  this  approach  is  illustrated  by  DISA’s 
success  (or  lack  thereof)  in  defining  common  data  elements  for  Global  Command  and  Control 
System.  To  date  they  have  achieved  only  partial  agreement  on  5  entities  (representing  on  the 
order  of  100  standard  data  elements);  they  reported  that  they  have  over  1 1,000  elements  to  go! 

The  introduction  of  the  XML  has  been  an  important  first  step  toward  achieving  interoperability 
at  the  syntactic  level.  Current  research  aims  to  build  on  the  XML  concepts  and  to  extend  the 
language  to  achieve  semantic  interoperability.  If  this  research  achieves  its  goals,  there  will  be  a 
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major  opportunity  to  achieve  semantic  interoperability  without  imposing  a  requirement  on  users 
to  have  complete  agreement  on  standard  data  elements. 

One  of  the  new  technologies  being  developed  to  support  semantic  interoperability  between 
systems  is  the  DARPA  Agent  Markup  Language  (DAML).  The  goal  of  DAML,  based  on  XML, 
is  to  provide  not  just  machine  readable,  but  machine  understandable  content  for  other  DAML 
enabled  software  agents,  programs  and  systems.  DAML  will  be  a  semantic  language  that  ties  the 
information  on  a  page  to  a  machine-readable  semantics  (ontology).  Language  compliance  will 
allow  for  military  and  commercial  information  technology  communities  to  develop  ontologies 
for  their  own  use  while  also  allowing  the  sharing  of  these  ontologies  between  organizations.  To 
address  the  adoption  of  DAML,  DARPA  is  working  with  the  World  Wide  Web  Consortium 
(W3C)  to  insure  that  such  technology  fits  within  future  W3C  recommendations  for  the  semantic 
web. 

Another  new  technology  that  promotes  rapid  heterogeneous  systems  interoperability  is  the  Agent 
Grid  from  DARPA’s  Control  of  Agent  Based  Systems  (CoABS)  program.  The  Agent  Grid 
constitutes  a  service-based  middleware  which  provides  shared  access  to  protocols,  services,  and 
ontologies  to  agents,  object,  and  systems.  The  Agent  Grid  is  built  using  Sun  Microsystem’s  Jini 
and  Java  Remote  Method  Invocation  which  provides  the  ability  for  agents  and  systems  to 
describe  the  services  and  information  they  can  provide  and  how  to  use  them.  The  grid  then  acts 
as  the  glue  between  these  systems  and  communities  of  agents. 

The  Scientific  Advisory  Board  believes  that  the  combination  of  the  CoABS  grid  and  DAML 
described  above  will  be  a  critical  enabler  for  the  Joint  Battlespace  InfoSphere  (JBI),  and 
recommends  that  the  AFRL  work  closely  with  DARPA  to  make  sure  that  these  technologies  are 
introduced  to  industry  and  transitioned  into  the  JBI  program  at  the  earliest  possible  time. 

1.5.3  Security 

Most  security  requirements  within  the  DII  COE  kernel  are  implemented  using  native  OS 
capabilities.  When  properly  configured,  native  OS  security  capabilities  meet  many  DII  COE 
user  requirements,  and  there  is  the  option  of  developing  capabilities  to  meet  requirements  that 
are  not  satisfied  by  the  OS.  DII  COE  system  integrators  can  also  use  COTS  security  solutions  as 
mission  applications,  or  as  COE  components,  depending  on  the  product,  its  market  share,  and  its 
status  with  respect  to  the  COE  process.  DISA  has  also  been  working  with  OS  vendors  to 
improve  the  security  of  their  products  and  has  implemented  a  process  for  assessing  the  impact  of 
vulnerabilities  identified  by  the  Infonnation  Assurance  community  on  DII  COE  products.  OS 
patches  are  identified  or  developed  and  incorporated  into  the  kernel  to  fix  security  problems  as 
appropriate. 

Security  of  the  kernel  has  improved  over  the  past  several  years  by  incorporating  a  fundamental 
change  in  kernel  delivery.  In  the  past,  system  integrators  were  responsible  for  configuring  the 
kernel  to  meet  their  security  needs.  Now,  the  kernel  is  delivered  pre-configured  in  a  locked 
down  state.  Systems  integrators  work  with  Program  Managers  and  the  Designated  Approval 
Authority  to  balance  security  risks  and  software  integration  needs.  Also,  the  kernel  undergoes 
considerably  more  security  test  and  evaluation  than  in  the  past.  Each  release  of  the  kernel 
undergoes  a  Kernel  Security  Assessment,  the  results  of  which  are  fed  back  into  the  development 
process,  and  vendors  if  necessary. 
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Finally,  security  is  a  part  of  the  DII  COE  compliance  and  software  acceptance  process.  There  is 
a  new  security  chapter  in  the  I&RTS,  adding  to  and/or  strengthening  each  COE  compliance 
level. 

The  process  outlined  above  is  reasonable.  The  real  security  vulnerabilities  are  not  likely  to  be  in 
the  individual  components  of  the  DII  COE  but  in  the  “seams”  as  one  integrates  components  from 
multiple  vendors,  whether  in  the  COE  itself  or  as  mission  applications.  This  is  an  area  where  an 
overall  security  architecture  is  badly  needed,  where  there  must  be  particular  attention  to  security 
in  system  testing,  and  where  new  technologies  must  constantly  be  examined  for  possible  use  in 
improving  security  and  to  see  whether  they  introduce  new  vulnerabilities. 

1.5.4  Costs,  Benefits,  and  Metrics 

We  do  not  know  what  DII  COE  costs.  Some  of  the  costs  are  borne  by  DISA,  while  other  costs 
are  passed  on  to  the  Commander  in  Chiefs,  Services  and  Agencies  (C/S/A).  The  DISA  costs 
include  support  for  the  management  process,  configuration  management,  production  engineering, 
and  software  development  for  the  kernel,  the  Integrated  Command,  Control,  Communications, 
Computers,  and  Intelligence  System  Framework — the  COP  toolkit — and  some  of  the  tools.  The 
C/S/A  bear  the  costs  for  staffing  working  groups,  sponsoring  new  components  not  already  in  the 
COE,  and  migrating  Mission  Applications  to  the  COE.  We  do  not  know  the  extent  of  the  costs 
borne  by  the  C/S/As.  One  of  the  key  issues  has  been  the  lack  of  funding  to  bring  new 
capabilities  into  the  COE.  Costs  are  expected  to  be  borne  by  the  C/S/A,  but  they  frequently  do 
not  have  the  funds.  The  lack  of  funding  is  a  de  facto  priority  system — no  funding  means  low 
priority. 

While  the  top-level  goals  for  DII  COE  are  to  improve  interoperability,  improve  functionality  for 
the  warfighter,  and  reduce  life-cycle  costs,  there  has  been  no  effort  to  quantify  any  of  these. 
Reports  from  Aerospace  Command  and  Control,  Intelligence,  Surveillance,  and  Reconnaissance 
Center  (AC2ISRC)  indicate  that  they  expect  to  spend  a  significant  part  of  their  funds  budgeted  to 
improve  functionality  on  complying  with  DII  COE.  Of  particular  concern  is  the  backward 
compatibility  provided  when  new  versions  of  DII  COE  are  released.  Processes  which  regularly 
evaluate  the  technical  impact  associated  with  changes  in  the  DII  COE  and  the  benefits  of  DII 
COE  mandates  against  mission  impact  and  program  costs  are  needed. 

1.5.5  Requirements  and  Mandates 

DII  COE  is  mandated  by  the  JTA.  The  JTA  is  promulgated  by  a  memo  dated  29  November 
1999,  and  signed  by  the  Undersecretary  of  Defense  (Acquisition,  Technology  and  Logistics),  the 
Assistant  Secretary  of  Defense  (Command,  Control,  Communications  and  Intelligence),  and  the 
J6  (Director,  Command,  Control,  Communications  and  Computer  Systems). 

Version  3.0  of  the  JTA  states,  “The  DII  COE,  as  defined  in  the  DII  COE  I&RTS,  is  fundamental 
to  a  Joint  System  Architecture  (JSA).  In  the  absence  of  a  JSA,  the  JTA  mandates  that  at  a 
minimum,  all  C2,  Combat  Support,  and  Intelligence  Systems  supporting  the  Joint  Task  Forces 
and  Combatant  Commands  will  use  the  DII  COE.  All  applications  of  a  system  that  must  be 
integrated  into  a  DII  platform  shall  be  at  least  DII  COE  I&RTS  level-5  compliant  (software  is 
segmented,  uses  DII  COE  Kernel,  and  is  installed  via  COE  tools)  with  a  goal  of  achieving 
Level  8.” 
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The  overall  requirements  process  takes  too  long  and  is  too  inflexible.  Spiral  development 
demands  that  a  trade  space  exist  between  requirements,  implementation  and  test/certification.  If 
we  expect  the  Cost  as  Independent  Variable  approach  is  to  be  successful,  and  any  usable 
products  are  to  be  delivered,  then  we  must  set  up  an  infrastructure  to  address  the  overall  process. 
Many  communities  must  re-think  their  business  activities:  from  the  budgeting  and  program 
objective  memorandum’ ing  perspective,  the  test  and  certification  view,  the  training  approach,  the 
deployment  mechanisms,  security  accreditation,  etc. 

We  must  continue  to  improve  installation  and  training  technology.  Parallel  testing  and 
certification  opportunities  must  be  exploited.  Distributed  configuration  management  is  needed  to 
allow  developers  access  to  software  resources.  The  ability  to  easily  perform  regression  testing 
must  be  in  place.  We  must  be  able  to  fund  technology  initiatives  as  technology  appears,  not  plan 
for  its  insertion  years  in  the  future. 

Finally,  the  users  must  be  an  integral  part  of  this  process.  This  means  providing  a  consistent  user 
base  to  guide  development,  with  the  empowerment  to  make  decisions  in  the 
requirements/implementation/testing  trade  space. 

1.6  Recommendations 

Many  of  the  DII  COE  issues  described  above  impact  multiple  organizations  because  of  the  joint 
nature  of  DII  COE.  While  these  recommendations  are  addressed  to  the  Air  Force,  the  actions 
will  involve  others,  particularly  DISA. 

•  Take  charge  of  your  own  destiny.  The  Air  Force  (SAF/AQ,  AC2ISRC,  and  ESC)  must  take  a 
leadership  position  to  steer  DII  COE  to  meet  Air  Force  needs. 

-  The  Air  Force  should  examine  DII  COE  mandates  and  accept  responsibility  for  providing 
waivers,  where  appropriate.  The  Designated  Acquisition  Authority  has  this  authority  now. 

-  The  Air  Force  should  institute  a  process  (spiral-like)  to  involve  all  affected  parties  in  steering 
DII  COE  to  meet  Air  Force  needs.  This  includes  balancing  costs,  operational,  and  technical 
needs. 

-  The  Air  Force  should  ensure  that  the  DII  COE  provides  sufficient  backward  compatibility  to 
meet  Air  Force  needs,  specifically  for  TBMCS. 

-  The  Air  Force  should  develop  the  capability  to  experiment  with  emerging  versions  of 
DII  COE  in  a  testbed  environment. 

•  Streamline  the  DII  COE  process.  The  Air  Force  (ESC/DI)  should  work  with  DISA  to 
streamline  the  DII  COE  development  and  compliance  processes.  This  includes: 

-  Getting  out  of  the  kernel  business  and  moving  to  more  reliance  on  the  commercial  sector. 

-  Allowing  certification  of  Windows-based  systems  to  be  done  by  complying  with  the 
Microsoft  Logo  Program  to  be  associated  with  Windows  2000  Service  Pack  2.  Explore 
similar  certification  arrangements  for  Unix-based  systems. 

-  Turn  the  execution  of  DII  COE  compliance  over  to  the  Services  and/or  approved  companies 
in  the  private  sector. 

•  Incorporate  new  technologies  into  DII  COE.  The  Air  Force  should  move  aggressively  (in 
conjunction  with  DISA)  to  accommodate  the  evolving  technology  base  in  DII  COE.  The  goal  is 
to  avoid  an  excessive  requirement  and  approval  process. 
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-  Embrace  opportunities  offered  by  web-based  technologies  emerging  from  the  commercial 
sector  (for  example,  World  Wide  Web  Consortium)  and  the  research  community  (for 
example,  DARPA  and  Rome  Labs) 

-  Seek  alternate  ways  to  provide  interoperability  by  exploiting  XML  and  by  exploiting  research 
on  semantic  interoperability. 

Insure  that  mechanisms  needed  to  support  the  JBI  (for  example,  publish  and  subscribe)  are 
identified  and  accommodated 

•  Do  cost  benefit  analysis  for  DII  COE.  Processes  should  be  established  which  regularly  evaluate 
the  technical  impact  of  changes  to  the  DII  COE  and  the  benefits  of  DII  COE  mandates  against  the 
mission  impact  and  program  costs. 

•  Look  beyond  DII  COE.  The  Air  Force  needs  to  ensure  that  the  appropriate  processes  are  in 
place  to  evolve  their  command  and  control  systems  with  the  changing  commercial  and 
technology  base: 

-  Move  from  a  platform  (hardware  and  software)  to  a  service  orientation.  JBI  is  moving  in  this 
direction. 

-  Develop  a  security  architecture  and  continuously  revise  it  as  technologies  and  threats  change. 

-  Accommodate  new  sources  of  system  development,  including  use  of  scripting  and  locally- 
developed  software. 

-  In  accommodating  these  changes,  develop  processes  that  ensure  the  integrity  of  the  systems 
that  are  to  be  fielded. 
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Chapter  5 

Report  of  the  People  and  Organization  Panel 


5.1  Introduction 

The  Air  Force  vision  for  global  aerospace  power  is  built  upon  a  foundation  of  “quality  people.” 

In  recognition  of  the  critical  contribution  of  skilled,  motivated  people  to  effective  command  and 
control  (C“),  the  Air  Force  Scientific  Advisory  Board  (SAB)  study  leadership  fonned  a  team  to 
focus  specifically  on  “People  and  Organization”  issues  and  their  implications  for  improvement  of 
the  future  Air  Force  theater  C  capability.  The  panel  was  asked  to  address  a  broad  range  of 
subject  matter  areas,  including  organizational  and  institutional  issues,  personnel  practices, 
training  of  C“  specialists,  and  human  interfaces  for  C  systems.  The  panel  members  included 
technical  specialists  from  industry  and  academia  with  expertise  in  various  aspects  of  human 
factors  along  with  retired  Air  Force  personnel  experienced  in  both  ground-based  and  airborne  C“ 
operations.  The  panel  membership  is  listed  in  Appendix  5B. 

Figure  5-1  illustrates  the  overall  scope  of  the  effort  undertaken  by  the  People  and  Organization 
Panel.  As  shown  in  the  diagram,  the  C“  system  can  be  conceptualized  as  a  combination  of 
resources  (hardware,  software,  and  people)  that  must  be  utilized  in  the  right  combination  to 
accomplish  a  mission  within  a  particular  operational  environment.  The  panel  was  asked  to 
review  current  Air  Force  practices  relative  to  the  human  factors  listed  in  Figure  5-1  and  assess 
their  impact  on  performance  and  mission-effectiveness  of  existing  C  systems  (see  Appendix  5A 
for  a  complete  description  of  the  panel  charter).  The  panel  then  formulated  specific 
recommendations  for  improvements. 

Organization  and  Institutic 

•  Vision,  Values,  Policies, 

•  Structure,  Doctrine 

•  Processes 

Personnel  Practices 

•  Skills  Management 

•  Career  Path 

•  Staffing 

Training 

•  Requirements 

•  Content  and  Curricula 

•  Methods  and  Technology 

Human  System  Interface 

•  Requirements  and  Standards 

•  Display  and  Control  Media/Technology 

•  System  Development  and  Acquisition  Practices 

Figure  5-1.  Subject  areas  investigated  by  the  People  and  Organization  Panel 


5.2  Approach  and  Visits 

Because  of  the  broad  scope  defined  by  the  panel  charter  and  limited  timeframe  for  the 
investigation,  the  collection  of  relevant  infonnation  represented  a  substantial  challenge  for  the 
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study  team.  The  panel  identified  and  contacted  organizations  that  could  provide  information  on 
current  problems  and  challenges,  ongoing  initiatives,  and  advanced  concepts  related  to  each 
subject  area.  Organizations  identified  included  government  agencies,  military  agencies, 
commercial  companies,  and  academic  institutions.  These  organizations  were  then  contacted  and 
briefed  on  the  purpose  and  scope  of  the  study.  Arrangements  were  made  to  secure  relevant 
information  by  means  of  site  visits,  telephone  conferences,  or  written  reports.  In  most  cases, 
data  collection  involved  a  visit  to  the  facility  to  obtain  briefings  or  demonstrations  and  to 
facilitate  direct  interchange  with  resident  experts  in  the  above  subject  areas.  Table  5-1  shows  the 
organizations  and  facilities  visited  during  the  course  of  the  study. 

Table  5-1.  Site  visits  completed  by  the  People  and  Organization  Panel 


ACC,  AC2ISRC  ,  Network  Operations  Security  Center  Langley  AFB 

Lockheed  Martin;  Boeing  Info.  Systems  Washington  DC 

U.S.  Navy;  the  Defense  Advanced  Research  Projects  Agency 
(C2-related  ATDs/ACTDs)  Washington  DC 

Air  Force  Fighter  Weapons  School/Red  Flag  . Nellis  AFB 

C2  Training  and  Innovation  Group;  C2  Battlelab  ...... .....Hurlburt  Field 

93rd  Air  Control  Wing  (JointSTARS)  Robins  AFB 

Air  Force  Agency  for  Modeling  and  Simulation  Orlando,  FL 

AFRL  Human  Effectiveness  Directorate  Wright-Patterson  AFB 

AFRL  Information  Directorate  Rome  Research  Site 

Air  Force  Electronic  Systems  Center  . Hanscom  AFB 

Boeing  Phantom  Works;  Space  and  Communications  Seattle,  WA 

U.S.  Navy  Command  Ship  Coronado  San  Diego,  CA 

5.3  Findings  and  Discussion 


2 

An  essential  prerequisite  for  improving  Air  Force  C  is  the  recognition  and  accompanying 
organizational  reinforcement  of  theater  C  as  a  warfighting  element  on  equal  footing  with  all 
other  combat  functions.  At  the  heart  of  this  recognition,  and  built  on  the  foundational  element  of 
“quality  people”  for  the  Air  Force  core  competencies,  is  the  establishment  of  a  trained  force  of 
C2  professionals,  dedicated  to  operational  C2  centers.  To  realize  the  vision  of  C2  as  a  highly 
integrated  and  effective  weapons  system,  the  human  dimension  in  C“  effectiveness  must  be 
addressed.  The  relevant  human-related  issues  can  be  grouped  into  the  following  categories; 

•  Institutions 

•  Organization 

•  Training 

•  Personnel  practices 

•  C2  system  design 

•  Human-system  interface  (HSI)  technologies 

A  discussion  of  the  panel  findings  regarding  each  area  is  presented  below.  Specific 
recommendations  are  provided  in  Section  5.4  of  this  report. 
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5.3.1  Institutions 

Status,  Authority,  and  Priorities.  The  absence  of  professional  status  for  the  “C2  warrior” 
contributes  to  the  low  priority  for  staffing,  resources,  and  funding  for  C  warfighting  functions. 
As  a  consequence,  the  system  defaults  to  improvised  solutions  in  response  to  crises.  Some 
elements  of  these  problems  are  being  addressed  by  Aerospace  Command  and  Control, 
Intelligence,  Surveillance,  and  Reconnaissance  Center  (AC2ISRC).  However,  the  Center  has  not 
been  vested  with  the  comprehensive  operational,  budgetary,  and  acquisition  authority  to  ensure 
that  standards  for  C2  operations  are  enforced  and  that  acquisition  and  modernization  are 
accomplished  in  a  prioritized  and  consistent  fashion  across  the  full  range  of  C"  systems.  The 
paradox  is  that  many  previous  studies  and  any  number  of  senior  Air  Force  leaders  have 
recognized  and  articulated  these  problems  and  the  changes  needed.  However,  the  institutional 
will  to  fully  implement  change  seems  to  be  lacking. 

C  as  a  Weapon  System.  In  its  entirety,  a  weapon  system  is  composed  of  dedicated  hardware, 
software,  support  logistics,  facilities,  personnel,  doctrine,  procedures,  training,  and  various  levels 
of  command  oversight.  Ideally,  a  weapon  system  is  defined  by  its  mission  and  a  specified 
operational  capability  that  is  described  in  a  concept  of  operations  (CONOPS).  Historically, 
having  the  status  of  a  “major  weapon  system”  has  served  to  focus  priority,  resources  and 
leadership  attention  on  the  system  and  its  enabling  resources.  Fundamental  skill  domains 
contributing  to  the  effectiveness  of  weapon  systems  are  often  referred  to  as  “core  competencies,” 
enhancing  their  value  and  relevance  as  perceived  by  the  general  population.  While  the  C2 
mission  area  requires  all  of  these  same  elements,  it  has  not  held  the  status  or  shared  in  the 
benefits  normally  accorded  a  traditional  weapon  system  and  its  enabling  competencies. 

The  Air  Force  leadership  has  stated  the  intent  to  treat  C2  as  a  “weapon  system.”  The  efforts 
under  way  to  develop  definitive  CONOPS  and  operational  architectures  for  major  elements  of 
the  C2  system  represent  important  steps  in  this  direction.  Obtaining  status  as  a  true  weapon 
system  implies,  however,  that  C  subsystems  such  as  the  Air  Operations  Center  (AOC)  will  be 
characterized  by  certain  key  attributes  that  are  not  fully  in  place  at  present.  Among  these  are 

•  Personnel  staffing,  skill  requirements,  and  crew  duty  allocations  driven  by  CONOPS 

•  Established  policy  for  system  manning  levels 

•  Standardized  doctrine  and  procedures  for  system  operation,  maintenance,  and  support 

•  Comprehensive,  current,  and  standardized  training  publications,  curricula,  and  methods 

•  Required  certifications  supported  by  regular  refresher  training  and  proficiency  checks 

•  A  system  program  office  with  overall  responsibility  and  accountability  for  requirements, 
acquisition,  and  planned  modernization 

•  A  structured  system  engineering  approach  to  development,  testing,  and  configuration 
management 

These  attributes  have  very  important  implications  for  human  effectiveness  in  C  operations.  It  is 
essential  that  the  Air  Force  leadership  follow  through  on  its  commitment  to  institutionalize  C2 
and  the  AOC  as  a  weapon  system  by  fully  implementing  these  elements  of  the  weapon  system 
concept. 

Processes  and  Documentation.  With  regard  to  processes,  considerable  written  guidance  for  the 
C  mission  exists,  but  the  documentation  is  generated  through  a  number  of  independent  channels 
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and  is  often  inconsistent.  For  example,  Figure  5-2  shows  three  different  functional  organizations 
for  an  AOC  documented  in  current  Air  Force  directives.  These  publications  outline  the 
functional  organization  of  an  AOC  and  specify  from  three  to  five  major  operations.  Applicable 
documents  include:  Joint  Publication  (JP)  3-56.1  (three  functional  areas),  Air  Force  Doctrine 
Document  (AFDD)  -2  (four  functional  areas),  and  Air  Force  Instruction  (AFI)  13-1  Vol.  3  (five 
functional  areas).  These  conflicting  directives  may  inhibit  standardization  of  the  baseline  AOC 
and  have  negative  implications  for  staffing,  training,  and  efficient  transition  from  peacetime  to 
wartime  operations.  This  example  also  highlights  a  disparity  between  Air  Force  Doctrine  and 
Joint  publications.  The  establishment  of  a  definitive  baseline  CONOPS,  resolution  of  conflicts  in 
directives  and  alignment  of  Air  Force  and  Joint  Doctrine  should  be  high  priorities  for 
improvement  of  C2  effectiveness. 


JP3-56.1  AFDD-2 


Figure  5-2. 


Disparity  in  AOC  Functional  Organizations  Based  on  Air  Force  Publications 


17,18,19 


2 

Acquisition  Framework.  The  approach  used  in  C~  acquisition  is  somewhat  fragmented  and 
could  benefit  from  a  more  coherent,  integrated,  user-driven  strategy  for  developing  and 
purchasing  systems.  The  current  structure  involves  numerous  program  elements  and  tends  to  be 
platform-  or  component-centric  rather  than  capability-centric.  For  this  reason,  stovepiped 
systems  are  prevalent  in  C2,  creating  problems  in  connectivity,  training,  and  program 
management.  Further,  many  systems  are  not  interoperable  with  other  joint  or  Air  Force  C“ 
systems,  contributing  to  less  than  optimum  combat  effectiveness.  Decisive  leadership  will  be 


17  JP  3-56.1,  “Command  and  Control  for  Joint  Air  Operations,”  14  November  1994. 

18  AFDD-2,  17  February  2000. 

19  AFI  13-1,  AOC  Vol.  3,  Operational  Procedures-Air  Operations  Center,  1  June  1999. 

5-4 


required  to  reshape  current  acquisition  strategies  and  to  seek  congressional  support  for  necessary 
process  improvements. 

5.3.2  Organization 

Operational  Air  Force  C  weapon  systems,  such  as  the  Airborne  Warning  and  Control  System 
(AWACS),  the  Joint  Surveillance  Target  Attack  System  (JointSTARS),  Rivet  Joint,  the  Airborne 
Battlefield  Command  and  Control  Center,  and  the  Ground  Theater  Air  Control  System  are 
equipped  with  advanced  sensors  and  have  access  to  a  large  body  of  valuable  intelligence, 
surveillance,  and  reconnaissance  (ISR)  information.  They  have  extensive  communications  and 
computer  processing  capability  integrated  into  their  architectures  to  enable  exploitation  and 
dissemination  of  their  products.  Most  important,  however,  they  have  a  worldwide  deployment 
mission  that  drives  their  day-to-day  planning  and  training.  They  prepare  for  combat  employment 
as  their  primary  mission.  These  systems  train  with  their  joint  and  Service  component 
counterparts  in  regular  simulation  and  live  events,  both  in  the  continental  United  States 
(CONUS)  and  in  theater.  An  example  is  the  deployment  of  JointSTARS  to  support  Anny  forces 
at  the  National  Training  Center  and  AWACS  involvement  in  the  Navy’s  Fleet  Battle 
Experiments.  In  addition,  operational  C  units  run  robust  daily  training  programs  for  the  initial 
qualification  and  upgrade  of  their  personnel. 

Only  at  the  top  level  of  our  CONUS-based  theater  C  ,  the  AOC,  are  part-time  operations  the 
nonn,  with  key  personnel  performing  C“  duties  as  an  adjunct  to  their  primary  staff  assignments. 

A  review  of  Blue  Flag  lessons  learned  reveals  shortcomings  in  this  approach  to  providing  C2 
warfighting  capability  to  the  Combat  Air  Forces.  The  AOC’s  elements,  assigned  to  the  CONUS- 
based  numbered  air  forces  (NAFs)  are  only  partially  staffed.  At  best,  they  train  as  a  system 
annually  during  Blue  Flag.  They  may  augment  their  supported  theater  commander  in  chief 
(CINC)  during  annual  training  cycles,  but  augmentees  are  widely  recognized  to  be  less  than 
knowledgeable  upon  arrival  in  theater  and  in  need  of  orientation  and  refresher  training.  Standing 
AOCs  (Operation  Southern  Watch,  Operation  Northern  Watch,  the  Combined  Aerospace 
Operations  Center  [CAOC]  at  Vicenza)  operate  with  only  a  handful  of  pennanent  staff; 
additional  staff  rotate  every  90  to  120  days.  With  the  onset  of  a  crisis,  staffing  ramps  up  rapidly 
but  in  an  ad  hoc  fashion,  in  part  because  the  personnel  system  does  not  support  ready 
identification  of  certified  personnel. 

Training,  manning,  and  modernization  initiatives  are  all  driven  by  organizations.  The  current 
NAF  AOC  lacks  the  structure  to  implement  solutions.  A  potential  solution  lies  in  establishing 
standing  NAF  AOCs  as  full-fledged  participants  in  the  C2  structure.  Establishing  a  full-time 
operational  AOC  at  a  designated  NAF  could  solve  a  number  of  C  problems.  Most  important  is 
the  placement  of  responsibility  for  training  and  equipping  directly  in  the  hands  of  a  single  agent. 
Management  of  this  unit,  its  employment  and  tasking  would  become  a  primary  responsibility  for 
a  designated  NAF  commander.  Critical  modernization  would  be  initiated  and  championed  by  a 
single  agent  acting  as  principal  sponsor  for  AOC  upgrades  and  standardization.  Coordination 
with  the  Air  Staff,  Electronic  Systems  Center,  and  the  AC2ISRC  would  be  managed  through  the 
tasked  NAF  commander. 

To  effectively  support  an  Aerospace  Expeditionary  Forces  (AEF),  there  must  be  a  comparable 
AOC  element  trained  and  ready  to  deploy  to  support  it.  The  C2  NAF  concept  provides  a 
management  vehicle  that  can  support  the  AEF  while  also  managing  the  low  density/high  demand 
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(LD/HD)  ISR  assets.  As  each  AEF  comes  into  its  scheduled  rotation  window,  the  NAF  AOC 
would  identify  the  AEF  team  scheduled  for  deployment.  Qualification  and  upgrade  training 
would  be  scheduled  and  managed  by  the  personnel  on  alert,  designated  by  name.  The  alert  team 
would  align  with  the  alerted  ISR  resources  to  ensure  effective  integration  of  these  elements  from 
day  one  of  any  action.  Current  ad  hoc  taskings  to  support  contingencies  should  be  minimized 
and  in- theater  lag  time  reduced. 

A  final  benefit  from  this  concept  is  that  each  theater  CINC  would  have  fully  trained  and 
experienced  C2  professionals  dedicated  to  support  combat  operations  in  theater.  Support  to 
standing  AOCs,  such  as  the  CAOC,  would  be  provided  by  designated  teams.  Blue  Flags  and 
annual  theater  exercises  would  be  supported  with  personnel  specifically  trained  in  the  AOC’s 
processes  and  procedures. 

5.3.3  Training 

The  Air  Force  does  not  have  in  place  a  fully  trained  force  of  C2  professionals  in  sufficient 
numbers  to  respond  efficiently  to  the  demands  of  a  major  theater  crisis.  Air  Force  leaders  lack 
the  necessary  training  and  experience  to  develop  the  full  complement  of  essential  warfighting 
skills,  particularly  at  the  operational  level  of  command.  The  current  approach  to  C2  training  does 
not  support  the  “train  the  way  you  fight”  doctrine  and  has  not  been  fully  integrated  with  the 
Expeditionary  Aerospace  Force  structure  and  duty  cycle.  Resources  and  priorities  for  C2  training 
are  not  comparable  to  other  weapon  systems,  and  the  opportunities  to  gain  necessary  skills  and 
experience  are  therefore  limited.  C2  duties  are  not  practiced  routinely  in  peacetime  and  are  often 
shared  with  staff  assigmnents.  These  staff  responsibilities  often  take  precedence  over  scheduled 
C2  training  opportunities,  since  perfonnance  in  these  staff  positions,  rather  than  warfighting 
skills,  is  seen  as  the  basis  for  promotion. 

Air  Force  personnel  assigned  to  other  weapon  systems  normally  experience  an  orderly 
progression  of  training  from  basic  military  training  (Officer  Training  School  [OTS],  Reserve 
Officer  Training  Corps  [ROTC],  etc.),  through  undergraduate  training  (Undergraduate  Navigator 
Training,  Undergraduate  Pilot  Training,  basic  maintenance  officer,  etc.),  to  specialized  training 
(FTU,  etc.)  that  leads  to  initial  qualification  and  mission-ready  status.  These  efforts  are  managed 
carefully  to  include  testing  and  certifications  along  the  way  and  then  are  periodically  revisited  to 
assure  currency  and  proficiency.  Such  is  not  the  case  for  C  specialists  today.  Because  C  lacks 
status  as  a  weapon  system,  formal  training  is  more  often  acquired  in  a  less  structured  fashion, 
often  through  on-the-job  training.  This  largely  ad  hoc  approach  to  training  produces  too  few 
senior  C2  professionals  with  the  complete  skill  set  and  qualifications  to  serve  effectively  as 
mentors. 

The  Air  Force  does  have  in  place  certification  requirements  for  C  specialists  and  training 
directives  (AFI  13-109,  Vol.  I)  that  mandate  required  training.  Well-designed  and  -administered 
C  courses  and  training  programs  are  also  available  at  Maxwell  Air  Force  Base  (AFB),  Nellis 
AFB,  and  Hurlburt  Field.  Collectively,  these  programs  constitute  a  large  proportion  of  the 
necessary  academic  content  to  support  a  professional  C  warrior  force  (see  Appendix  5C  for 
course  descriptions).  While  a  relatively  complete  training  curriculum  exists,  only  about 
20  percent  of  AOC  personnel  have  actually  completed  the  “mandatory”  training  required  for 
certification  in  their  individual  specialties.  The  part-time  nature  of  C2  assignments,  combined 
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with  staffing  shortfalls  and  failure  to  fully  utilize  existing  training  opportunities,  creates  a 
downward  spiraling  effect — fewer  opportunities  supported  by  fewer  people. 

Integration  of  ground-based  C  into  the  major  weapons  school  exercises  is  lacking,  as  is  the 
presence  of  interactive  and  adaptive  AOC  functions  in  Red  Flag.  Even  the  dedicated  venues  of 
Blue  Flag  have  evolved  into  qualification  events  centered  around  Air  Tasking  Order  (ATO) 
production  instead  of  operational  exercises  that  strengthen  C2  skills.  This  is  primarily  because 
participants  are  temporarily  assigned  on  an  ad  hoc  basis  from  their  staff  positions  without  the 
benefit  of  adequate  preparation  or  daily  C2  operations.  At  the  higher  levels,  the  Joint  Force  Air 
Component  Commander  (JFACC)  and  AOC  Director  often  have  their  first  experience  in  these 
roles  with  the  advent  of  a  crisis.  The  end  result  is  a  lack  of  sufficient  numbers  of  fully  trained, 
professional  C  leaders,  at  all  levels,  to  staff  and  execute  the  warfighting  functions  of  the  AOC. 
Some  of  the  specific  training  challenges  that  impact  C2  effectiveness  may  be  summarized  as 
follows: 

•  The  need  to  prepare  future  C2  leaders  to  move  from  being  ATO  generators  and  managers  to 
become  commanders  of  aerospace  forces 

•  Difficulty  in  delivering  the  right  training  to  the  right  person  at  the  right  time 

•  Limited  ability  and  opportunity  for  units  at  all  levels  (air  component  and  operational  unit)  to 
provide  job  qualification  training  and  continuation  training 

•  Lack  of  standardization  of  procedures  and  processes  within  and  across  major  weapon  systems  and 
functional  communities 

•  Lack  of  a  structured  method  for  presenting  and  completing  standardized,  accessible  training 
products  and  materials  at  the  point  of  delivery 

•  Lack  of  an  ability  to  track  and  monitor  availability  and  status  of  personnel  with  critical  skills  to 
support  AOC  and  AEF  operations  (for  example,  targeting,  collection  management,  ISR 
operations,  airspace  battle  managers,  S1DO  and  FIDO) 

•  Inability  of  personnel  to  attend  critically  needed  training  due  to  high  operations  tempo  and 
personnel  tempo 

•  Reductions  in  availability  of  centrally  funded  training  and  quotas  for  school  slots 

•  Lack  of  an  enterprise-wide  skills  management  system  to  provide  visibility  at  all  levels  into  force 
readiness  posture 

•  Lack  of  opportunity  for  daily  AOC  training  and  operations  comparable  to  other  systems  and 
functions 

Theater  C  training  and  readiness  could  be  strengthened  through  the  development  of  clearer  and 
more  concise  training  requirements  based  on  the  C2/AOC  CONOPS  and  Mission-Essential  Task 
Lists  (METLs).  CONOPS-driven  training  requirements  can,  in  turn,  provide  a  solid  foundation 
for  improving  training  content,  curricula,  and  methods.  In  addition  to  formal  training  for  C2 
specialists,  C2  training  must  be  included  in  basic  military  training  for  all  Air  Force  specialties. 
Opportunities  to  obtaining  this  foundation  of  basic  C2  principles  include  professional  military 
education  (PME)  and  the  basic  courses  for  various  occupational  specialties  (for  example,  the 
maintenance  officer  course  and  initial  qualification  in  nearly  all  weapons  systems).  These 
training  improvements  must  be  supported  by  an  expanded  skills  tracking  and  management 
system  to  fully  exploit  their  benefits  (see  Section  5.3.4).  To  enable  and  honor  the  “train  as  we 
intend  to  fight”  doctrine,  C"  must  become  an  integral  component  of  nearly  all  Air  Force 
opera tions-oriented  training  programs. 
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5.3.4  Personnel  Practices 

There  is  a  widely  held  belief  among  Air  Force  personnel  that  C  skills  and  experience  are  not 
valued  assets  for  career  advancement.  Indeed,  there  is  a  common  perception  that  assignment  to 
an  AOC  is  a  career  dead  end.  The  C2  community  suffers  from  the  absence  of  a  defined  and 
viable  career  path,  the  lack  of  adequate  rewards,  and  recognition  for  C  experience,  and  the 
inability  to  attract  and  retain  high-quality  personnel  as  core  C2  specialists.  Personnel  representing 
other  functional  domain  expertise  tend  to  avoid  excursions  into  C"  assignments  and  lack 
exposure  to  fundamental  C2  principles,  further  limiting  the  pool  of  talent  available  to  augment 
core  C  staff  in  time  of  crisis.  To  solve  these  problems,  the  Air  Force  must  establish  a 
recognized  “C2  warfighter”  career  track.  Career  promotions  and  incentives  must  better  reward 
the  skills  and  expertise  of  the  C2  warrior  to  attract  and  retain  qualified  individuals. 

Skill  and  experience  requirements  for  C2  warriors  and  for  AOC  positions  are  not  well  defined  or 
documented.  In  time  of  war,  the  AOC  staffing  problem  is  further  compounded  by  difficulties  in 
tracking  skilled  professionals  in  the  current  personnel  system  due  to  lack  of  adequate  experience 
identifiers.  Consequently,  contingency-driven  staffing  requirements  result  in  a  pick-up  solution 
that  is  slow  to  reach  critical  mass  and  is  heavily  dependent  on  ad  hoc,  on-the-job  training. 
Today’s  personnel  tracking  system  must  be  improved  to  rapidly  and  accurately  identify 
personnel  who  have  the  necessary  skills,  experience,  and  certifications  to  staff  essential  AOC 
functions. 

An  expanded,  enterprise-wide  tracking  system  is  needed  to  better  manage  the  human  resources 
and  provide  the  mechanism  to  develop  and  deliver  standardized,  approved  training  to  the  right 
person  at  the  right  time.  Such  a  system  would  also  enable  functional  and  force  managers  to  gain 
insight  into  the  progress,  status,  and  level  of  effort  across  the  force,  including  critical  skill  sets. 

It  would  also  provide  access  to  distributed  databases,  including 

•  Skills  management  (tracking  certification  status  of  critical  skill  sets — initial  qualification  training 
(IQT),  mission  qualification  training  (MQT),  and  continuation  training  (CT) 

•  Personnel  management  and  record  keeping 

•  Input  for  training  curriculum  development 

•  Virtual  classroom  (on-line  conferencing  and  collaboration  tools) 

•  Knowledge  capture  (digital  library  for  reference  and  reuse) 

Efforts  are  under  way  at  the  AC2ISRC  to  augment  the  personnel  tracking  system.  Specific 
complementary  functions  offered  by  this  expanded  skills  management  system  concept  could 
include 

•  Ability  to  identify  and  validate  C2  personnel  training  requirements  from  the  unit  level  up  through 
the  AOC  level  in  a  virtual  collaborative  work  environment 

•  Ability  to  deliver  courseware  and  distributed  learning  by  means  of  a  virtual  institute  or  campus 
using  Web-based  technology 

•  Ability  to  document  and  track  training  accomplishments  for  designated  active-duty  and  reserve 
component  personnel  to  support  AEF/AEW  and  AOC  personnel  requirements  management 

•  Ability  to  track  certifications  to  satisfy  identified  personnel  qualification  and  certification 
requirements  for  critical  skill  sets 


5-8 


Ability  to  provide  automated  force  readiness  status  based  on  established  metrics  for  commanders 
at  all  levels 


5.3.5  C2  System  Design 

2 

Arguably,  there  is  no  other  warfighting  function  where  the  HSI  is  more  important  than  in  C 
because  of  the  volume,  complexity,  importance  and  time-critical  nature  of  decision  making 
required.  As  shown  in  Figure  5-3,  the  effectiveness  of  the  HSI  is  also  a  key  element  in 
establishing  a  “common  operational  picture,”  which,  in  turn,  is  essential  for  collaborative 
decision  making  and  interoperability  across  organizations  and  platforms. 
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Figure  5-3.  The  Human-System  Interface  Contribution  to  Interoperability 


The  study  team  reviewed  and  assessed  current  Air  Force  practices  for  assuring  effective  human- 
system  integration  in  acquiring  and  modernizing  C2  systems.  The  panel  was  briefed  on  the 
processes  used  in  developing  and  testing  of  several  representative  airborne  and  ground-based 
systems  that  play  key  roles  in  theater-level  battle  management.  These  included  the  Theater 
Battle  Management  System  (TBMCS),  JointSTARS,  AWACS  avionics  upgrades,  and  the  Multi- 
Source  Tactical  System.  The  panel  also  received  briefings  or  documentation  on  the  HSI 
integration  approach  in  use  for  current  Air  Force  combat  aircraft  development  and  upgrade 
programs  (for  the  F-22,  B-1B,  and  C-130).  The  scope  of  these  briefings  and  discussions 
included  definition  of  HSI  requirements,  function  allocation,  crew  complement  and  workload, 
HSI  design,  accommodation  of  user  preferences  and  physical  characteristics,  performance 
metrics,  and  test  methods. 

In  general,  it  was  found  that  the  priority  assigned  (and  resources  provided)  to  ensure  effective 
HSI  in  C  systems  is  low  in  comparison  to  other  weapon  systems.  While  the  Air  Force  has 
recognized  the  impact  of  HSI  design  on  mission  effectiveness  of  combat  aircraft  (for  example, 
the  F-22  and  Joint  Strike  Fighter),  there  seems  to  be  comparatively  little  awareness  or 
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appreciation  for  the  value  of  a  well-designed  human  interface  for  the  decision  support  systems 
that  enable  effective  C2.  Some  problems  associated  with  the  present  Air  Force  approach  to  the 
HSI  for  C2  systems  may  be  summarized  as  follows: 

•  Lack  of  definitive  CONOPS  to  serve  as  a  basis  for  design  and  testing  of  the  HSI 

•  Lack  of  a  systematic  process  for  definition  of  HSI  requirements  and  metrics 

•  Inadequate  or  late  involvement  of  operational  users  in  system  development  (particularly  leaders 
and  commanders) 

•  Failure  to  establish  or  apply  standards  to  ensure  HSI  consistency  within  and  across  systems  and 
platforms 

•  Failure  to  fully  exploit  available  HSI  technologies  and  decision  support  tools 

•  Lack  of  definitive  performance  criteria  for  HSI  effectiveness 

•  Insufficient  human  engineering  capability  (trained  staff  and  facilities)  within  product  centers  for 
C2  systems 

While  the  panel  found  some  examples  of  sound  HSI  design  practices  (for  example,  the  AWACS 
and  C-130  avionics  upgrades),  their  application  across  programs  has  been  inconsistent.  In  some 
cases,  this  has  resulted  in  user  interfaces  that  are  unnecessarily  complex,  counter-intuitive,  and/or 
difficult  to  learn.  While  the  magnitude  of  the  effect  is  difficult  to  estimate,  these  deficiencies 
undoubtedly  have  a  negative  impact  on  user  workload  and  productivity  as  well  as  on  the 
timeliness  and  accuracy  of  decisions  and  actions.  These  factors  will  in  turn  have  negative 
implications  for  other  personnel  issues,  such  as  staffing  and  training. 

It  seems  clear  that  the  Air  Force  could  benefit  substantially  from  the  application  of  a  more 
rigorous  approach  to  the  design  and  testing  of  the  HSI  for  C  systems.  The  necessary 
knowledge,  methods  and  tools  are  already  in  use  in  other  Air  Force  weapon  system  applications. 
If  an  effective  human  engineering  program  for  C  systems  is  undertaken  early  in  the  acquisition 
cycle,  the  costs  of  implementing  it  are  minimal  relative  to  the  potential  performance 
improvements. 

The  Office  of  the  Secretary  of  the  Air  Force  has  acknowledged  the  need  for  increased  emphasis 
on  human-system  integration.  In  a  recent  memorandum  to  the  Air  Force  leadership, 

Lt  Gen  Stephen  Plummer  (SAF/AQ)  stated,  “Integrating  the  human  into  the  early  development 
of  all  Air  Force  acquisitions  is  a  critical  component  to  increasing  operational  effectiveness, 
minimizing  follow-on  modifications  and  reducing  life  cycle  cost.  The  acquisition  community 
must  engage  HSI  more  effectively  early  in  the  acquisition  process.”20  While  this  statement 
represents  an  important  first  step,  it  is  essential  that  the  Air  Force  acquisition  leadership  put  in 
place  the  necessary  process,  resources,  and  infrastructure  to  ensure  that  these  goals  are  realized. 
Section  5.4.5  provides  specific  recommendations  regarding  the  establishment  of  an  improved 

process  for  human-system  integration  and  the  essential  mechanisms  for  institutionalizing  this 

2 

process  in  the  acquisition  of  Air  Force  C  systems. 

5.3.6  Human-System  Interface  Technologies 

The  panel  reviewed  HSI  technologies  and  their  applications  in  current  Air  Force  C  systems. 

The  panel  concluded  that  the  Air  Force  has  not  fully  exploited  HSI  technologies,  automation,  and 

20  Memo  from  SAF/AQ,  Lt  Gen  Stephen  B.  Plummer,  Principal  Deputy  Assistant  Secretary  of  the  Air  Force 
(Acquisition),  entitled  “Awareness  of  Human  Systems  Integration  in  Air  Force  Acquisition,”  June  2000. 
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decision  support  tools  that  are  available  or  under  development  for  other  applications.  This 
finding  is  consistent  with  the  conclusions  reached  by  the  Technology  Panel,  which  found  that  a 
number  of  useful  HSI  concepts  in  use  in  the  commercial  sector  and  Department  of  Defense 
(DoD)  have  yet  to  be  applied  to  Air  Force  C  systems  (see  Chapter  4).  The  People  and 
Organization  Panel  then  assessed  advanced  HSI  technologies  and  concepts  for  potential  C2 
applications.  For  the  purposes  of  this  study,  the  panel  confined  its  assessment  of  HSI 
technologies  to  those  available  in  the  relatively  near  term  (the  next  5  years).  The  reader  may  also 
find  useful  a  more  comprehensive  review  of  HSI  technologies  provided  in  Volume  2  of  the  1999 
SAB  Study  on  the  Joint  Battlespace  InfoSphere21. 

Table  5-2  summarizes  the  HSI  technology  assessment.  The  table  includes  concepts  in  use  or 
under  development  in  the  private  sector,  as  well  as  those  from  other  DoD  applications.  The  table 
also  highlights  some  potential  operating  benefits  to  be  realized  and  a  projection  of  technology 
availability.  Recommendations  regarding  several  of  the  most  promising  HSI  technology 
applications  are  described  further  in  Section  5.4.6. 


21  SAB-TR-99-02,  “Building  the  Joint  Battlespace  InfoSphere,  Vol.  II:  Interactive  Information  Technologies,” 
17  December  1999. 
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Table  5-2.  Assessment  of  HSI  Technologies  for  Potential  C2  Applications 


Technology 

Application 

Benefits 

Availability  Date * 

Controls  &  Displays 

Automatic  speech 
recognition 

AOC 

Faster  spinup  time  for  augmentees 

ATO  created  30  percent  faster 

Reduced  training  time  overall 

Now,  for  TBMCS 
application 

6  months  for  other 
applications 

Wearable  displays 

AOC;  training; 
personal  gear; 
intelligence; 
operations;  etc 

Several  wearable  design  options  (wrist, 
knee,  chest,  around  neck,  on  head) 
allow  hands-free  mobile  display  viewing 

See  also  “portable  displays’’ 

Now,  for  some 
applications 
(Commercial-off-the- 
shelf  available) 

Augmented 
reality — incorporate 
real-time  view  of 
battlefield  and 
record 

Intelligence;  planning 
and  wargaming; 
rehearsal;  operations; 
training 

Better  situation  awareness  through 
synthetic  enhancement  of  the  live 
battlespace;  reduces  pattern 
recognition  uncertainty 

1  year  (non-immersive) 

Immersive  reality 

Intelligence;  planning 
and  wargaming; 
rehearsal;  operations; 
training 

Intuitive,  high-fidelity  simulation  of  the 
battlespace  improves  transfer  of 
training,  reduces  pattern  recognition 
uncertainty 

Now,  for  training 

3-6  years  for  C2 
systems 

Volumetric  displays 

Intelligence;  planning 
and  wargaming; 
rehearsal;  operations 

Intuitive,  high-fidelity  representation  of 
the  battlespace  reduces  pattern 
recognition  uncertainty 

2-3  years  for  true  3-D 
symbols  and  graphics; 

4-6  years  for  complex 
scene-filling  true  3-D 
images 

Stereoscopic 

displays 

Intelligence;  planning 
and  wargaming; 
rehearsal;  operations 

Improves  spatial  decluttering;  reduces 
pattern  recognition  uncertainty 

Now 

3-Audio 

AOC 

JointSTARS 

AWACS 

Voice  communication  with  more  people 
and  lower  rates  of  confusion 

Now 

Untethered  C2 

(magnetic  sensing, 
infrared,  etc.) 

AOC 

Ability  to  use  display  technologies,  for 
example,  data  wall,  without  physical 
constraints 

4-6  years;  depends  on 
technology;  see 
“portable  displays” 

Large  screen 
seamless  projection 
supported  by  a 
multiheaded  display 
driver  (2  to  20 
display  units  driven 
as  a  single  ultra- 
high  resolution  wall- 
size  display 
system) 

AOC 

More  flexible  display  configuration; 
ability  to  review  more  data 
simultaneously 

1- 3  years;  now — 
knowledge  wall 
demonstrated  Aug  2000 
on  U.S.S.  Coronado 
(10  ft  tiled  with  1-  to 

2- in.  seams);  seamless 
overlapping  image  tiled 
designs  demonstrated 
at  Honeywell,  Sarnoff 

Portable  displays, 
palmtops,  and 
tablets  flexible 
displays 

AOC 

Personal  gear 

Continued  connectivity  while  in  transit; 
lightweight,  reconfigurable  workspace 
options 

Now — 5  years  with 
unclassified  networks;  1 
to  5  yrs  with  classified 

Technology  availability  date  =  approximate  timeframe  when  the  technology  could  be  used  in  an  operational  system.  It  is  assumed 
that  initial  prototypes  of  each  technology  would  be  deployed  rapidly,  with  block  upgrades  to  follow. 
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Technology 

Application 

Benefits 

Availability  Date * 

Controls  &  Displays 

Touch-sensitive 
displays  (any  size) 
coupled  with 
gesture  and 
handwriting 
recognition 

AOC 

JointSTARS 

AWACS 

Faster,  more  intuitive  entry  of  graphical 
data;  enables  reprogrammable  buttons; 
more  natural  collaboration  with  large- 
screen  displays;  provides  keyboard 
functions  for  portable  displays 

Now 

Flat  panel  displays; 
AMLCD,  DMD,  EL, 
OLED,  ETC. 

AOC;  all  C4ISR 
applications; 

JointSTARS; 

AWACS,  Airborne 
Laser 

Better  situation  awareness,  higher 
resolution  than  CRTs;  lighter  weight, 
more  reliable  and  smaller  footprint 
terminals;  less  power 

1-3  years  for  AMLCD, 
DMD,  EL;  3-5  years  for 
OLED 

Ultra-thin  clients  for 
client-server 
architecture 
coupled  with  flat 
panel  displays 

AOC 

JointSTARS 

AWACS 

Lighter-weight  user  terminals;  ease  of 
workspace  reconfiguration  for  custom 
team  collaboration 

Now 

Biometrics 

AOC 

Improved  security  in  user  identification 
(see  smart  card) 

2  years 

Smart  card  user 
identification 

AOC 

Rapid,  consistent  logon  and 
configuration  of  desktops;  custom 
desktop  and  network  permissions  travel 
with  user 

Now 

Visualization 

Perspective  view  of 
the  battlespace 

Planning, 
intelligence,  and 
operations 

Better  situation  awareness;  reduced 
uncertainty  in  pattern  recognition; 
supports  faster,  more  reliable  decision 
making 

1  year 

Layered  imagery 

Planning, 
intelligence,  and 
operations 

Better  situation  awareness;  reduced 
uncertainty  in  pattern  recognition; 
supports  faster,  more  reliable  decision 
making 

Now-for  limited  map 
and  imagery  products 

Logistics  control 
and  information 
support  (LOCIS) 

Wing  log  C2 

Customizable  and  adaptive  dynamic 
user  interface  that  allows  holistic  view 
of  fused  information  to  support  wing- 
level  operations 

2  years 

Realistic  icons  for 
commanders 

C2-wide 

Better  situation  awareness;  reduced 
uncertainty  in  pattern  recognition; 
supports  faster,  more  reliable  decision 
making 

Now 

Technology  Availability  Date  =  Approximate  timeframe  when  the  technology  could  be  used  in  an  operational  system.  It  is 
assumed  that  initial  prototypes  of  each  technology  would  be  deployed  rapidly,  with  block  upgrades  to  follow. 
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Technology 

Application 

Benefits 

Availability  Date * 

Decision  Support  Systems 

Bed-down  critic 

Logisticians 

Faster  bed  down;  Intelligent  agents 
catch  unintended  negative 
consequences  of  plan  changes 

3  years 

Uncertainty 
management  using 
Bayesian 
inferences 

AOC 

Better  decisions;  ability  to  gauge  the 
quality  of  inputs  into  the  decision 
process. 

3-5  years 

Communication 
workarounds; 
provide  or  model 
communication 
routes  and 
constraints 

C2 

Interoperability;  faster  message 
dissemination,  fewer  missed  handoffs. 

4-6  years 

Proactive  collection 
plan  display 
(predictor  displays; 
what  if s) 

AOC 

Faster  replanning.  Anticipate  what  will 
happen  next  in  a  collection  plan,  instead 
of  fixating  on  the  information  that  is 
already  gathered  and  becoming 
obsolete.  See  the  consequences  of 
changing  the  collection  plan. 

4-6  years 

Recall  campaign 

JFACC 

Rapid  dissemination  of  changes  to  an 
ATO,  to  tighten  up  the  decision  cycle 
during  replanning — for  example,  if 
targets  are  destroyed,  a  “recall 
campaign”  will  quickly  notify  the  affected 
parties. 

4-6  years 

Team  calibration 
(intent)  (distributed 
systems) 

C2 

Fewer  coordination  surprises;  support 
distributed  teams  for  planning  and 
executing  together,  without  requiring 
lengthy  video  teleconferencing. 

Now 

Overall  campaign 
progress 

C2 

Allow  planners  to  review  the  data  used 
to  estimate  progress  toward  objectives 
for  better  replanning. 

4-6  years 

Work-centered 
decision  support 
using  intelligent 
agents 

Air  Mobility 
Command’s  Tanker 
Airlift  Control  Center 

More  accurate  and  robust  decision 
making  for  airlift  planning,  scheduling, 
and  operations.  More  timely  problem 
identification  and  resolution. 

Initial  versions-now 

Advanced  versions-in 

2-3  years 

AOC  process 
information  capture, 
recall,  and  reuse 

AOC 

System  captures  audio  and  video  of 

AOC  actions.  This  rich  dataset  is  then 
indexed  and  correlated  to  screen 
captures  of  the  datawall  and  individual 
workstations.  This  will  allow  “instant 
replay”  of  AOC  actions  and  provide  the 
data  to  develop  improved  decision 
support  tools  and  C2  training. 

Now 

LOCIS 

Wing-level  decision 
makers 

Provides  proactive  decision  support 
through  the  use  of  customizable 
intelligent  agents  monitoring  critical 
information  based  on  thresholds  and  the 
use  of  a  desktop  simulation  to  provide 
what-if  capability. 

2  years 

Technology  Availability  Date  =  Approximate  timeframe  when  the  technology  could  be  used  in  an  operational  system.  It  is 
assumed  that  initial  prototypes  of  each  technology  would  be  deployed  rapidly,  with  block  upgrades  to  follow. 
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Technology 

Application 

Benefits 

Availability  Date * 

Training  Hardware/Software 

Aerospace 
operations/training 
suite  initiative 

C2  for  ISR 

Solves  latency  issues  surrounding  C2 
responsiveness  issues  of  ISR  assets, 
increases  situational  awareness  to 
maintain  positive  control  over  ISR 
assets,  supports  data  fusion  and  data 
morphing,  and  integrates  air  and  space 
ISR  mission  training  and  rehearsal 
architectures. 

4-6  years 

Brief/debrief  system 

C2 

Allows  weapons  directors  to  integrate 
information  during  distributed  mission 
training  (DMT) — C2  brief/debrief  events. 

1  -2  years 

Human 

performance 

modeling 

C2 

Improves  realism  of  C2  training  through 
accurate  representation  of  human 
decision-making  processes. 

3-5  years 

MCE  interface  with 
DMT/JSAF 

MCE 

STEs 

JSTEs 

DMT 

Other  C2  Platforms 

•  DMT  and  JSAF  provide  higher 
fidelity  training 

-  Realistic  aircraft  maneuvers 

-  Immediate  kill  removal 

-  Rapid  generation  and  archival  of 
training  scenarios  for  specific 
instructional  objectives  with  JSAF 

-  Manned  DMT  cockpits  provide 

communication  practice 

-  DMT  provides  opportunity  to  train 
as  part  of  the  combat  team  in  the 
JSB 

-  JSAF  does  not  require  simulation 

“drivers”;  this  should  result  in 
reduced  manning 

•  Training  from  home  unit  via  DMT 
results  in  cost  savings  on  temporary 
duty  and  reduced  scheduling 
conflicts 

•  Interface  creates  the  potential  to 
expand  to  include  STEs/JSTEs  and 
training  with  additional  C2  platforms 
via  DMT 

•  Reduced  training  time  anticipated 

•  Expands  DMT-  C2  to  include 
operational  equipment 

If  existing  DIS/CD2 
converter  can  be 
located,  immediate 
solution 

If  DIS/CD2  converter 
has  to  be  developed,  7 
months  from  receipt  of 
funding 

Virtual  Tactical 
Operations  Center 

Army  and  Air  Force 
intelligence  training 

Web-based  virtual  environment  for 
training  C2  warfighter  and  information 
superiority  mission  rehearsal  scenarios 

Now 

Technology  Availability  Date  =  Approximate  timeframe  when  the  technology  could  be  used  in  an  operational  system.  It  is 
assumed  that  initial  prototypes  of  each  technology  would  be  deployed  rapidly,  with  block  upgrades  to  follow. 
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5.4  Recommendations 


5.4.1  Institutions 

Without  establishing  the  foundation  of  strong  institutional  value  for  theater  C  ,  most  of  the  other 
actions  recommended  in  this  study  will  enjoy  little  sustained  impact.  Theater  C2  must  be  elevated 
in  status,  representation,  and  resources  (both  personnel  and  funding)  to  the  levels  appropriate  for 
an  essential  warfighting  function.  The  following  actions  are  considered  essential  in  establishing 
an  appropriate  level  of  visibility  and  priority  for  C  in  the  Air  Force  culture: 

•  As  an  initial  step,  the  Air  Force  leadership  should  strengthen  C2  in  its  vision  statement  and  long- 
range  planning  to  clearly  identify  C2  as  the  fundamental  integrating  function  for  commanding 
aerospace  power. 

•  The  Air  Force  should  establish  an  Air  Staff  leadership  position  with  the  responsibility  and 
authority  to  operationalize  C2,  establish  the  AOC  as  a  weapons  system  and  ensure  overall  C2 
integration.  The  Air  Force  must  define  all  aspects  of  the  weapon  system  and  assign  clear 
responsibility  for  their  implementation  and  support. 

•  The  panel  strongly  supports  the  completion  and  implementation  of  the  draft  Air  Force  C2 
CONOPS.  It  is  essential  that  the  Air  Force  follow  through  on  this  initiative,  resolve 
inconsistencies  in  current  documentation,  and  ensure  that  the  baseline  CONOPS  is  used  in  a 
disciplined  fashion  to  standardize  doctrine,  procedures,  staffing,  and  training  for  C2  systems. 

•  C2-related  program  elements  must  be  consolidated  (to  a  minimum  number)  to  enable  more 
effective  integration  and  oversight  of  requirements,  plans,  investment  strategy  and  priorities,  and 
interoperability  standards  across  the  full  spectrum  of  C2  systems. 

5.4.2  Organization 

The  principal  recommendation  regarding  C  organization  is  to  stand  up  daily,  under  the 
leadership  of  the  Air  Combat  Command  (ACC)  C2  operational  commander,  the  necessary  forces 
to  provide  C2  operations,  training,  and  integration  for  all  warfighting  systems.  The 
organizational  construct  is  illustrated  in  Figure  5-4.  This  “standing  AOC  capability”  would  link 
ISR  and  battle  management  forces  for  daily  operations  and  training.  Strike  assets  would  operate 
off  an  ATO  or  “ATO-like”  order  generated  by  the  standing  AOC  capability  and  would  link  to 
such  AOC  entities  in  Flag  and  joint  exercises.  The  goal  is  to  make  the  transition  from  peace  to 
war  as  seamless  as  possible. 
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C2  NAF 

DEPLOYABLE  AOC 

C2  for  AEF 

AEF 

Management  of  ISR  BM 
(LD/HD) 

AEF 

Management  of  10/ 

AEF 

Information  Warfare 

C2  ISR  Augmentation  Teams 

1 


Experiment  integration  (JEFX) 
Prototype  Evaluation 
User  Evaluation  Acq  Feedback 
Red  Flag / 

Mission  Effectiveness  Support 


AEF  Management 
AFFOR  functional  support 
Logistics,  Communications 
Force  Protection,  Personnel  for 
Contingency  Operations,  etc. 


Deployed/Theater  \ 
AOC  Support  ) 


CAOC  Fwd 
Nellis  AFB 
Det  3 

Operational  Support  Center 
Langley  AFB 

Det  1 

AFC2TIG 
Hurlburt  Fid 
Det  2 

Mission: 

Mission: 

Mission: 

Initial  Qualification  Training 
Advanced  AOC  Training 
Augmentee  Training 
C2  Exercises,  Innovation 
and  Experimentation 


Figure  5-4.  The  C2  NAF  Concept 


The  intent  of  this  organizational  concept  is  to  operationalize  the  CONUS  AOC  activities  and  to 
increase  the  priority  of  the  C2  warfighting  system  by  making  it  the  principal  responsibility  of  a 
CONUS  NAF  commander.  This  commander  should  report  directly  to  the  senior  ACC 
operational  commander.  The  commander  would  provide  not  only  principal  parts  of  the  standing 
AOC  capability,  but  also  management  of  the  LD/HD  C  and  ISR  assets  of  the  information 
operations  and  information  warfare  resources.  The  C2  NAF  would  be  organized  to  align  core 
AOC  personnel  in  parallel  with  each  AEF  for  rapid  deployment  if  needed.  Staffing  and 
assignments  would  align  with  the  functions  of  the  AOC  CONOPS,  consistent  with  the  personnel 
manning  documents,  and  would  rely  on  a  mix  of  active-duty,  reserve,  guard,  and  civilian 
personnel.  The  C2  NAF  would  also  be  responsible  for  developing  AOC  operational  standards 
established  for  the  functions  defined  in  the  AOC  CONOPS.  The  standards  would  provide  a 
baseline  capability  of  common  AOC  functions  while  accommodating  tailored  aspects  needed  for 
specific  regional  deployments.  Supporting  the  C  NAF  would  be  the  three  key  organizations 
noted  above  and  in  Figure  5-4,  but  in  this  construct  they  would  be  specifically  detailed  to  the  C2 
NAF.  Other  NAFs  and  AOCs  would  maintain  the  level  of  C  emphasis  deemed  necessary  by 
their  commanders. 

Implementing  a  single  NAF  AOC  organizes  existing  training,  experimentation,  and  operational 
elements  into  a  cohesive,  focused  organization.  This  essentially  converts  three  related  but  stand¬ 
alone  elements  into  a  single  functional,  cross-supporting  unit.  Training  at  all  levels  would  be 
centralized  at  the  existing  Hurlburt  Field  C2  Training  and  Innovation  Group  (C2TIG).  The 
operational  element  at  Langley  AFB,  previously  designated  as  AOC  Rear,  becomes  the  daily 
functioning  Operational  Support  Center.  Experimentation  focuses  on  the  C  laboratory  element 
at  Nellis  AFB  executing  the  task  of  prototyping  and  evaluating  new  equipment  and  concepts 
before  transition  into  the  employment  and  training  areas.  The  C  Battlelab  and  the  Air  Force 
Research  Laboratory  (AFRL)  should  work  collaboratively  to  support  this  process  by  maturing 
promising  technologies  and  demonstrating  their  readiness  for  transition.  A  single  NAF  AOC 
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provides  the  structure  to  coordinate  actions  between  mutually  supporting  elements.  It  will  also 
increase  the  quality  of  support  provided  to  the  standing  theater  AOCs  and  the  AEFs. 

5.4.3  Training 

A  critical  element  in  moving  toward  “C  as  a  weapons  system”  is  the  implementation  of  training 
programs  comparable  to  those  for  other  weapon  systems.  Training  requirements,  curricula,  and 
performance  standards  should  be  derived  from  approved  CONOPS  and  the  METL  for  C  .  The 
Air  Force  should  establish  a  conventional  training  program  for  the  C2/AOC  weapons  systems  to 
include  the  necessary  qualification  tests  and  certifications  to  ensure  proficiency  and  currency. 

Air  Force  Major  Commands  (MAJCOMs)  should  be  charged  with  ensuring  compliance  with  all 
C  training  requirements  and  directives.  Commanders  should  make  C  training  accomplishment 
a  part  of  nonnal  reporting  to  higher  authorities.  Any  AOC  with  an  operational  plan  commitment 
should  report  training  status  to  the  applicable  air  component  and  theater  CINC  J-3.  MAJCOM 
Inspectors  General  should  inspect  units  responsible  for  C2  and  report  capability  (including 
training)  based  on  applicable  METLs. 

A  “standing  AOC”  capability  should  be  established  and  charged  with  conducting  daily 
operations  and  training  missions  in  peacetime.  ACC  and  Joint  Forces  Command  should  stand  up 
the  necessary  forces  daily  to  provide  training  and  operational  practice  for  all  basic  theater  C“ 
functions.  ISR  and  battle  management  forces  should  link  with  an  AOC  or  “AOC-like”  entity  for 
daily  training.  Strike  assets  should  operate  from  an  ATO  or  “ATO-like”  order  and  link  to  an 
AOC  for  Flag  and  CINC-directed  exercises.  AOC(s)  should  be  used  to  drive  force-level  CT, 
composite  force  training,  exercises,  advanced  tactical  training  (Weapons  School/ME),  and 
experimentation.  These  training  initiatives  should  include  measurable  training  objectives  for  the 
appropriate  level  of  C  activity.  To  the  extent  possible,  actual  operational  links  should  be 
established  with  the  next  layer  of  C2  nodes  and  between  other  represented  functional  activities 
(creating  horizontal  and  vertical  integration). 

C  training  should  be  tied  to  AEF  spin-up  and  reconstitution  training  cycles.  As  specific  rotation 
schedules  are  established  for  the  AEFs  (including  LD/HD  assets)  and  the  specific  training 
requirements  for  those  forces  are  specified,  two  aspects  of  C  training  must  be  included.  First, 
the  entire  force  (operations,  support,  force  protection,  communications,  etc.)  should  include  C2 
training  and  should  practice  the  use  of  their  respective  C  elements  daily.  Second,  the  C 

specialists  from  the  Squadron  Operations  Center,  the  Wing  Operations  Center  and  the  personnel 

2 

who  will  support  the  forward  AOC  should  all  receive  a  commensurate  level  of  spin-up  C 
training  and  should  practice  their  specific  C2  functions  regularly. 

The  Air  Force  should  actively  explore  the  feasibility  and  practical  utility  of  using  DMT  concepts 
and  technologies  to  enhance  the  quality  and  availability  of  C  training  and  fulfill  the  goal  of 
“training  the  way  we  intend  to  fight.”  Advanced  DMT  concepts  exploit  emerging  weapon 
system  connectivity,  in  combination  with  advanced  simulation  and  modeling  technology,  to 
enable  real-time  collaborative  operations  among  geographically  separated  systems.  DMT 
technologies  offer  the  potential  to  blend  real,  virtual,  and  constructive  environments  to  produce  a 
high-fidelity  training  experience  tailored  to  the  mission  need  and  resource  constraints.  As  DMT 
capabilities  expand  to  mirror  the  operational  environment,  the  distinction  between  training  and 
operational  domains  will  be  systematically  reduced  or  eliminated.  Only  the  specific  objectives 
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and  outcomes  of  a  particular  application  will  dictate  use  of  the  weapon  system,  the  simulator, 
and/or  the  constructive  models  as  these  become  largely  interchangeable  tools. 

As  outlined  in  the  1999  SAB  study  on  Operations  Other  Than  Conventional  War,  these  higher 
levels  of  integration  enable  development  of  a  Dynamic  Mission  Readiness  Environment 
(DMRE)  that  can  perfonn  additional  functions  beyond  that  of  distributed  training.  These 
technologies  can  be  used  to  support  a  wide  range  of  functionality,  including  experimentation,  test 
and  evaluation,  tactics  development  and  validation,  operations,  safety  assessment,  and  risk 
management.  DMT  and  DMRE  offer  the  potential  to  greatly  improve  the  vertical  and  horizontal 
integration  of  C“  and  AOC-level  activities  with  those  at  the  wing  and  squadron  levels,  providing 
the  capability  for  daily  immersion  in  the  dynamic  operational  environment.  This  advanced 

9 

capability  should  be  pursued  in  an  incremental,  spiral  fashion  concurrent  with  other  ongoing  C 
initiatives. 

5.4.4  Personnel  Practices 

A  comprehensive  effort  to  strengthen  C  professional  career  development  should  be  instituted  in 
the  Air  Force  with  principal  responsibility  assigned  to  AF/XO  and  AF/DP.  Figure  5-5  identifies 
the  major  elements  that  must  be  in  place  to  establish  and  maintain  a  viable  force  of  professional 
C“  warriors. 


C2  Career 
Advancement 
Opportunities 


Incentives  for 
Acquiring  C2  Skills 
and  Experience 


Figure  5-5.  Elements  Enabling  the  Professional  C  Warrior  Force 


The  first  step  is  development  of  the  professional  warfighter  career  track.  The  AC2ISRC  efforts 
in  the  C2  warrior  focus  area  for  career  path  development  are  in  line  with  this  step,  but  we  urge 
the  expansion  of  current  thinking  to  institutionalize  the  “aerospace  warfighter  track”  illustrated  in 
Figure  5-6  as  a  distinctive  career  path  within  the  Air  Force. 
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SAB-TR-99-01,  Technology  Options  to  Leverage  Aerospace  Power  in  Operations  Other  Than  Conventional  War, 
Vol.  1:  Study  Summary,  February  2000;  information  on  DMT  is  on  pp.  10,  52-55. 
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Figure  5-6.  The  Professional  Aerospace  Warfighter  Track 
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In  addition  to  notionally  defining  the  professional  C  warfighter  career  track,  Figure  5-6 
highlights  the  facts  that  the  advancement  opportunities  would  be  clear  to  all  and  that  visible 
equivalency  with  the  staff  track  for  advancement  would  be  institutionalized.  It  is  further 
recommended  that  all  Air  Force  personnel  receive  some  foundation  in  fundamental  aerospace 
warfighting  principles,  including  C  ,  as  part  of  their  basic  education  at  the  entry  level.  A 
requirement  should  also  be  established  for  formal  C2  training  or  experience  as  a  prerequisite  for 
promotions  above  Lieutenant  Colonel.  Establishing  fully  functional  AOCs  and  the  expansion  of 
training  opportunities  recommended  in  Sections  5.4.2  and  5.4.3  would  greatly  facilitate  the 
realization  of  this  career  path  alternative. 

A  second  critical  step  is  the  expansion  of  personnel  data  management  to  establish  an  enterprise¬ 
wide  qualification  tracking  system  that  supports  education  and  training,  maintains  personnel  and 
training  records,  and  provides  the  personnel  code  designations  at  a  level  sufficient  to  rapidly 
identify  the  C2  skill  set  of  individuals.  Again,  the  AC2ISRC  has  initiated  an  effort  to  at  least 
clarify  and  expand  the  Software  Engineering  Institute  codes.  This  initiative  should  be  endorsed 
but  extended  further  to  enable  complete  and  efficient  access  to  the  databases  on  personnel 
management,  special  skills,  and  training  and  to  other  relevant  databases.  A  comparison  of  the 
existing  personnel  tracking  scheme  and  the  expanded  skills  management  framework  is  presented 
in  Figure  5-7. 
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Figure  5-7.  Expanded  Capability  for  Tracking  of  Personnel  Skills  and  Experience 


For  the  above  measures  to  be  effective,  they  must  be  supported  by  an  incentive  structure  that 
provides  tangible  evidence  of  the  value  and  priority  assigned  to  C2  by  the  Air  Force  leadership. 
Promotion  opportunities  for  C2  specialists  must  reflect  the  importance  of  the  jobs  they  perform 
and  the  level  of  competence  with  which  they  execute  their  jobs.  Some  possible  actions  to 
strengthen  the  perceived  value  of  C  include 

•  Explore  the  Chief  of  Staff  of  the  Air  Force  “contribution-based  pay”  initiatives  such  as 
professional  warfighter  pay  for  qualified  colonels  similar  to  medical  pro-pay  and  the  aviation 
continuation  bonus  (that  is,  implementation  for  all  functional  domains,  including  C2) 

•  Provide  promotional  opportunities  honoring  the  premise  that  “all  warriors  are  created  and  treated 
equal”  (that  is,  a  parallel  to  joint  assignment  and  promotion  potential  initiatives) 

•  Make  career  advancement  and/or  preferred  assignments  contingent  on  C2  training,  experience, 
and  qualifications 

•  Re-orient  the  bonus  system  to  reward  qualified  volunteers  for  hard-to-fill,  remote,  and/or  hardship 
assignments 

•  Establish  a  course  or  program  of  weapons  school  caliber  that  results  in  a  specialty  designation  for 
key  aerospace  command  positions  and  enhanced  promotion  opportunities  for  graduates 

In  combination  with  the  improved  training  opportunities  and  daily  operations,  these  measures 
provide  the  foundation  upon  which  a  professional  C2  warrior  force  can  be  built  and  maintained. 

It  is  essential  to  note,  however,  that  all  of  the  elements  identified  in  Figure  5-5  are  inter¬ 
dependent  and  must  be  addressed  in  a  balanced,  coordinated  fashion  to  realize  the  desired  results. 

5.4.5  C2  System  Design 

Effective  integration  of  operational  experience  and  human  engineering  design  principles  must  be 
accomplished  early  in  the  HSI  development  process,  since  they  often  impact  architectural  and/or 
software  design  decisions  that  are  prohibitively  expensive  to  change  at  later  stages  of 
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development.  For  this  reason,  a  structured,  systems  engineering  approach,  comparable  to  that 
employed  routinely  in  the  development  of  the  HSI  for  combat  aircraft,  should  be  applied  in  the 
acquisition  and  modernization  of  future  C2  systems. 

Figure  5-8  shows  an  example  of  a  process  for  improved  human-system  integration.  The  diagram 
shows  a  fundamentally  mission-driven  approach,  with  requirements,  functions,  operator  tasks, 
and  performance  metrics  all  derived  directly  from  (and  traceable  to)  the  mission.  This  process 
also  heavily  emphasizes  user  involvement  at  all  stages  of  system  development  and  testing,  using 
rapid  prototyping  and  part-task  simulation  tools  to  actively  engage  users  in  assessing  alternatives 
and  evaluating  operational  utility  as  the  design  evolves.  The  iterative  nature  of  this  approach  is 
entirely  compatible  with  spiral  development  and  provides  for  effective  transition  from 
development  to  operations,  sustainment  and  incremental  upgrades. 
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Figure  5-8.  Human-System  Integration  Development  Process 


Several  actions  should  be  assigned  by  SAF/AQ  for  implementation  by  the  Air  Force  Materiel 
Command  and  its  product  centers  to  institutionalize  this  type  of  systems  approach  to  HSI 
integration  in  the  acquisition  process.  These  include 

•  Establish  a  structured  process  like  that  in  Figure  5-8  to  ensure  effective  HSI  integration 

•  Establish  usability  goals  as  key  performance  parameters 

•  Include  HSI  effectiveness  criteria  in  the  source  selection  process 

•  Tailor  and  apply  Military  Standard  1472  and  Military  Handbook  46855  as  appropriate 

•  Recommend  establishment  of  HSI  compliance  criteria  and  processes  for  Defense  Information 
Infrastructure  Common  Operating  Environment  certification 

•  Require  training  in  HSI  for  program  managers  (similar  to  the  U.S.  Army  MANPRINT  program) 

2 

An  important  action  for  the  ACC  C  operational  leadership  is  to  define  a  reference  mission  and 
baseline  CONOPS  prior  to  the  initial  cycle  in  the  spiral  development  process  for  new  C  systems. 
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In  addition,  a  multi-disciplinary  HSI  advisory  group,  including  both  HSI  professionals  and 
operators,  should  be  established  to  oversee  the  implementation  of  the  HSI  process. 

5.4.6  Human-System  Interface  Technologies 

Selected  examples  of  technologies  with  near-term  potential  for  C  applications  are  described 
below.  It  is  recommended  that  the  AC2ISRC,  in  cooperation  with  AFRL  and  the  C2  Battlelab, 
investigate  their  utility  and  feasibility  (along  with  others  listed  in  Table  5-2)  through  prototyping 
and  experimentation. 

•  Automated  speech  recognition  (ASR)  technology  is  sufficiently  mature  to  provide  an  intuitive 
interface  for  an  operator.  ASR  would  allow  the  operator  to  bypass  the  menu  structure  by  means 
of  natural  language  commands.  The  payoffs  would  be  faster  creation  of  the  ATO  with  fewer 
errors.  Faster  spinup  of  augmentees  would  also  be  facilitated. 

•  3-D  audio  displays  can  drastically  increase  the  intelligibility  and  effectiveness  of  multi-channel 
speech  communications  by  spatially  separating  the  apparent  locations  of  speech  signals  presented 
to  the  operator  over  headphones.  This  makes  it  much  easier  to  monitor  multiple  simultaneous 
talkers  for  critical  messages  and  to  focus  attention  on  the  critical  talker  in  the  presence  of  other 
competing  speech  messages.  3D  audio  displays  also  make  it  easier  to  determine  the  origin  of 
speech  messages  and  can  improve  situational  awareness  by  providing  intuitive  information  about 
the  locations  of  objects  relative  to  the  listener.  3D  audio  is  a  mature  technology  that  has  been 
demonstrated  in  numerous  flight  tests  and  can  be  inexpensively  implemented  in  new 
communications  systems. 

•  Untethered  technology  is  being  developed  to  allow  battle  commanders  in  Information 
Operations  (10)  and  C2  operational  environments  mobile  access  to  the  information  and  people  in 
their  organization,  even  when  they  are  not  physically  near  their  organization’s  computers  and 
databases.  These  technologies  include,  wearable  computers,  handheld  and  palmtop  computers, 
and  personal  digital  assistants.  This  line  of  technology  development  will  facilitate  battle 
commander  interactions  with  wall-size  and  PC-based  information  displays  and  operational 
information  databases,  as  well  as  facilitate  communications  with  other  command  staff  as  they 
move  from  place  to  place  within  the  organization.  They  will  also  allow  the  use  of  a  wide  variety 
of  computer  peripherals,  such  as  speech  generation  technology  and  laser-based  visual  display 
controllers,  without  the  cumbersome  “umbilical  cords”  typically  required  to  use  these 
capabilities.  Many  warfighter  organizations  have  identified  the  need  for  untethered,  mobile 
technologies  to  support  operational  battle  staffs  as  a  significant  factor  in  improving  human 
decision  making  in  wartime  environments  in  the  future. 

•  Simple  decision  support  systems  that  model  the  dynamics  and  uncertainty  of  the  work 
environment  using  Bayesian  inference  techniques  can  be  used  to  support  contextual  attention 
focusing  and  alerting  of  the  warfighter.  These  systems  would  provide  a  “flag”  (for  example,  an 
on-screen  alert  or  an  audible  tone)  when  critical  event  thresholds  are  exceeded.  Any  alerting 
would  be  provided  with  the  current  work  context  taken  into  account  to  ensure  that  the  alert  is 
offered  in  the  right  format  at  the  right  time  and  that  it  does  not  increase  the  cognitive  burden  on 
the  warfighter  (see  Appendix  5D  for  further  detail). 

•  Information  visualization  technologies  are  available  to  provide  commanders  and  their  staffs 
with  displays  to  aid  their  comprehension  of  large  volumes  of  data.  Visualization  tools  shift 
information  processing  from  lexical  to  spatial  realms  to  enable  rapid  discovery,  understanding, 
and  presentation  of  data.  AOC  visualizations  can  be  used  in  mission  preparation  and  planning 
and  in  mission  monitoring  and  assessment  to  portray  the  combined  (air,  space,  and  information) 
tasking. 
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•  AOC  recording  capability  could  provide  the  AOC  with  “performance  instrumentation”  that  is 
similar  to  that  used  to  characterize  and  improve  the  performance  of  test  aircraft.  There  is  an 
emerging  capability  to  record  screen  captures  of  the  displays  in  the  AOC  at  regular  intervals. 
Tools  must  be  developed  that  help  commanders  and  operators  better  understand  the  processes 
employed  in  the  AOC — so  as  to  rapidly  interpret  anomalies  and  adjust,  compensate,  or  change  the 
processes  as  decision  cycles  increase  in  speed,  complexity,  and  frequency.  Academic  researchers 
have  developed  process  capture  and  reuse  tools  that  can  record  audio  and  video  of  AOC 
activities.  This  multimedia  data  can  then  be  indexed  by  screen  capture  shots  taken  from  the  data 
management  systems  that  the  team  uses  in  the  AOC  (for  example,  large-screen  tactical  display  or 
individual  workstations).  This  could  produce  an  easily  navigated  and  reusable  record  of  AOC 
activity  during  operations  and  exercises.  Such  a  system  could  be  used  for  briefings,  de-briefings, 
crew  changeover,  post-mission  effectiveness  assessment,  requirements  definition,  training, 
experimentation,  and  development  of  decision  support  tools. 

The  field  of  cognitive  systems  engineering  can  also  provide  improvements  to  the  methods  and 
tools  employed  in  developing  C  decision  support  systems.  Some  of  the  more  promising  tools 
for  C2  applications  include 

•  Cognitive  Work  Analysis — a  systems  approach  to  identifying  the  constraints  in  a  domain  and 
using  these  constraints  to  guide  the  design  process 

•  Cognitive  Task  Analysis — a  set  of  methods  for  describing  the  cognitive  skills  needed  to  perform 
a  task 

•  Decision-Centered  Design — the  use  of  cognitive  task  analysis  to  specify  the  difficult  decisions 
and  to  use  these  as  a  basis  for  designing  HSIs  and  decision  support  systems 


5-24 


Appendix  5A 

People  and  Organization  Panel  Charter 

The  panel  served  as  the  technical  ann  to  advise  the  Concept  and  System  Definition  Panel  on 
human-system  integration  matters  relevant  to  the  2005  system  implementation.  The  panel  also 
made  recommendations  to  the  Acquisition  Panel  on  process  improvements  to  ensure  that  human- 
system  requirements  are  adequately  addressed  in  procurement  of  future  systems  and  in  near-term 
upgrades  to  existing  systems.  The  scope  of  effort  addressed  human-system  integration  issues  for 

•  Ground-forward 

•  Ground-reachback 

•  Airborne  battle  management  C2 

2 

The  panel  assessed  the  allocation  of  functions  to  humans  and  automation  in  present  Air  Force  C 
systems,  and  the  process  and  criteria  for  making  these  decisions.  The  panel  was  also  charged 
with  identifying  technologies  and  methods  to  optimize  utilization  of  human  and  automated 
resources  to  maximize  operating  efficiency. 

9 

With  regard  to  the  HSI,  the  panel  was  asked  to  consider  information  flow  in  both  directions  (C 
flow-down  and  feedback  mechanisms).  The  study  focused  on  presentation  of  relevant,  critical, 
timely,  accurate  information  to  decision  makers  at  all  levels.  This  included  dissemination  and 
presentation  of  all  mission-essential  information  and  the  establishment  of  necessary  levels  of 
situation  awareness  for  commanders,  analysts,  planners,  and  aircrews.  The  panel  was  asked  to 
recommend  technological  improvements  in  the  areas  of  display  media,  control  devices, 
automation,  and  decision-aiding  to  enable  needed  improvements  in  C  systems.  The  panel  also 
assessed  the  readiness  of  key  HSI  technologies  for  near-tenn  (2005)  and  long-tenn  applications. 

The  panel  addressed  personnel-related  issues  that  impact  C  system  effectiveness,  including 
selection,  placement,  training,  and  certification  of  C2  specialists.  This  effort  focused  on  problems 
associated  with  meeting  the  demands  of  high-tempo  expeditionary  deployments  and  their  impact 
on  the  skills,  qualifications,  readiness,  and  retention  of  personnel.  The  panel  made 
recommendations  regarding  concepts  and/or  processes  to  help  ensure  that  the  right  person  can  be 
immediately  deployed  and  employed  in  response  to  time-critical  threats.  Current  Air  Force 
organizational  practices  for  C2  were  reviewed  to  determine  whether  they  are  conducive  to 

•  Rapidly  getting  qualified  people  (and  equipment)  to  the  crisis  scene 

•  Ensuring  that  training  and  readiness  are  effective  and  “as  we  fight” 

•  Providing  career  ladders  for  the  people — officers  and  enlisted 

•  Applying  contractor  support  where  appropriate 

•  Controlling  personnel  tempo 

The  panel  was  also  asked  to  identify  and  address  human-system  issues  that  impact  integration  of 
C2  systems  for  joint  or  coalition  operations.  These  findings  took  into  account  lessons  learned 
from  recent  Air  Force  deployments  and  combat  operations. 
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Appendix  5B 

People  and  Organization  Panel  Membership 

Mr.  Jeffery  B.  Erickson,  Chair 
Manager,  Crew  Systems 
The  Boeing  Company 

Col  Lynn  Carroll,  USAF  (Ret) 

Private  Consultant 

Col  Roger  Carter,  USAF  (Ret) 

Program  Manager,  Advanced  Information  Systems 
Lockheed  Martin  Corporation 

Dr.  Emily  Howard 
Technical  Fellow 
The  Boeing  Company 

Dr.  Miriam  E.  John 

Vice  President,  California  Division 

Sandia  National  Laboratories 

Maj  Guy  Jones,  USAF  (Ret) 

Senior  Systems  Analyst 
SenCom  Corporation 

Dr.  Gary  Klein 

Chief  Scientist  and  Chairman  of  the  Board 
Klein  Associates  Inc. 

Prof.  M.  Elisabeth  Pate-Comell 

Department  Chair,  Management  Science  and  Engineering 
Stanford  University 

Col  Bruce  Queen,  USAF  (Ret) 

Director,  Advanced  Program  Development  Airborne  Ground  Surveillance  &  Battle  Management  Systems 
Northrop  Grumman 

Dr.  John  Reising 

Technical  Advisor,  Crew  System  Integration  Division 
AFRL/HE 

Lt  Gen  John  B.  Sams,  Jr.,  USAF  (Ret) 

Director,  C17  Field  Services 
The  Boeing  Company 

Col  Hugh  Smith,  USAF  (Ret) 

Manager,  C2  Operation 

TRW,  Systems  and  Information  Technology  Group 
Advisor:  Col  Marc  Lindsley 

Executive  Officer:  Maj  Juan  R.  Berrios,  ACC/INXX 
Technical  Writer:  Capt  John  M.  Feland,  USAFA/DFEM 
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Appendix  5C 

Available  Command  and  Control  (C2)  Training  Opportunities 

Joint  Forces  Air  Component  Commander  (JFACC)  Course.  The  JFACC  Course  is  the 
senior  (Joint-Service  0-7  level)  professional  military  education  course  offered  by  the  Air  Force 
to  prepare  potential  JFACCs  for  theater-level  leadership  responsibilities.  Particular  emphasis  is 
placed  on  air  power  employment  in  theater-level  operations  using  Theater  Battle  Management 
Core  System  (TBMCS)  and  other  related  equipment  that  will  be  available  to  future  JFACCs.  The 
JFACC  course  is  4.5  working  days  long — 3  days  at  Maxwell  Air  Force  Base,  Alabama,  and 
1.5  days  at  Hurlburt  Field,  Florida. 

Joint  Air  Operations  Senior  Staff  Course  (JSSC).  The  JSSC  is  a  senior  professional  military 
training  program.  The  course  uses  presentations,  discussions,  and  physical  equipment  to  provide 
an  overview  of  the  planning,  coordination,  integration,  employment,  and  implementation  of  air 
operations  strategy  in  joint  operations.  The  program  is  designed  to  prepare  colonels  (or  0-6 
equivalents)  and/or  specifically  selected  lieutenant  colonels  (or  0-5  equivalents),  selected  by 
their  respective  Numbered  Air  Forces  or  equivalent  organization,  for  senior  leadership 
responsibilities  in  a  Joint  Aerospace  Operations  Center  (JAOC).  Presentations  by  a  General 
Officer  JFACC  and  three  current  directors  from  three  JAOC  locations  lead  off  the  program, 
followed  by  each  Service’s  operating  considerations  in  a  JAOC.  Course  length  is  4.5  days. 

Command  and  Control  Warrior  Advanced  Course  (C2WAC).  The  purpose  of  the  C2WAC  is 
to  prepare  selected  Air  Force  officers  to  perfonn  duties  that  require  advanced  knowledge,  skills, 
and  ability  in  the  C2  processes  supporting  the  Joint  Force  Air  Component  Commander  or 
Commander,  Air  Force  Forces,  decision  making  at  the  operational  level  of  war.  In  keeping  with 
the  mission  of  the  C2  Training  and  Innovation  Group,  the  C2WAC  contributes  to  advancing  the 
C  state  of  the  art.  Individuals  entering  this  course  should  be  field-grade  officers,  normally  with 
a  minimum  of  1  year  experience  in  an  AOC,  across  the  functions  of  A-l  through  A-6,  including 
space,  information  operations,  and  mobility. 

Graduates  of  the  C“WAC  should  be  qualified  to  assume  supervisory  positions  (ccll/di  vision 
chief)  within  an  AOC. 

Joint  Aerospace  Command  and  Control  Course  (JAC2C).  JAC2C  focuses  on  C2  of  joint  air 
operations  in  a  theater  battle  at  the  operational  level  of  war.  This  course  covers  basic  doctrine, 
mission,  and  organization  of  the  services;  the  Theater  Air  Ground  System,  command,  control, 
and  communications  systems;  intelligence  support  capabilities;  tactical  missions  and  major 
weapons  systems  used  in  joint  operations;  capabilities  and  limitations  of  C2  warfare  concepts  and 
strategy;  and  computer  tools  used  in  current  operations.  The  course  includes  lectures,  seminars, 
hands-on  computer  activities,  a  C2  exercise  prior  to  the  final  exam,  and  end-of-course  Initial 
Qualification  Training  certification  by  functional  area. 

Joint  Aerospace  Systems  Administrator  Course  (JASAC).  JASAC  trains  selected  individuals 
in  the  fundamentals  of  UNIX,  and  Windows  NT  System  Administration  Tenninal  Control 
Protocol/Intemet  Protocol  networking  and  communications  protocols,  relational  database 
TBMCS  administration.  The  course  focuses  on  individuals  assigned  to  system  administration 
duties  within  the  JAOC,  Numbered  Air  Forces,  composite  wings,  or  related  joint  organizations  or 
facilities.  Course  length  is  40  days. 
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Joint  Aerospace  Computer  Applications  Course  (JACAC).  JACAC  trains  selected 
individuals  in  the  fundamentals  of  TBMCS  operations,  focusing  on  training  individuals  required 
to  use  TBMCS  in  a  JAOC,  other  joint  organizations,  or  closely  related  facilities.  Individuals 
attending  the  course  will  normally  be  assigned  duties  at  a  JAOC,  Battlefield  Coordination 
Element,  Control  and  Reporting  Center,  or  other  component  facility.  Course  length  is  4  days. 

Joint  Combat  Search  and  Rescue  (JCSAR)  Coordinator  Course.  JCSAR  Coordinator 
Course  provides  individuals  with  needed  information  for  functioning  in  a  Joint  Search  and 
Rescue  Center  (JSRC)  and  to  be  aware  of  the  dynamics  involved  in  one.  The  course  exposes 
students  to  the  procedures  and  requirements  for  establishing  and  running  a  JSRC  or  a 
component-level  Rescue  Coordination  Center.  A  cursory  overview  of  the  Personnel  Recovery 
program  will  be  provided.  This  and  many  other  aspects  will  be  used  to  recover  personnel  in 
distress  in  an  Area  of  Operations.  Course  length  is  4  days. 
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Appendix  5D 

Risk-Based  Decision  Support  Systems  for  Commanders 
Elisabeth  Pate-Cornell 


Quantification  of  uncertainties,  for  example,  probabilities  of  target  destruction  in  combat 
assessment,  is  currently  done  informally  based  on  experience,  at  least  by  some  commanders. 

This  process  includes  sequential  updating  of  the  probability  of  success,  based  on  pilot  reports 
and  sensor  data.  It  also  involves  a  threshold  of  probability  above  which  the  commander  is 
confident  enough  that  a  given  target  was  destroyed  to  proceed  with  further  operations. 
Automation  of  this  individual  thinking  process,  through  small,  simple,  computerized  systems,  is 
feasible  and  would  be  helpful  in  managing  the  fog  of  war.  Applications  include  combat 
assessment  and  choice  of  sensor(s)  for  a  given  task. 

Based  on  Bayesian  logic  and  probabilistic  risk  estimates,  these  combat  decision  support  systems 
could  automatically  provide  a  “flag”  when  specified  thresholds  of  probability  are  exceeded. 

These  systems  have  to  stand  alone  and  be  easy  to  use.  They  could  be  implemented,  for  instance, 
in  small  hand-held  computers  that  could  be  docked  into  larger  systems  when  useful  statistics  can 
be  found  elsewhere.  Key  input  will  include  the  probability  of  an  event  before  reports  and 
signals,  the  probabilities  of  errors  (false  positives  and  false  negatives)  in  intelligence  reports  and 
sensor  data,  and  the  thresholds  above  which  the  probability  of  the  event  of  interest  is  high 
enough  that  there  is  no  need  for  additional  infonnation.  Some  of  these  data  (for  example,  the 
performance  of  sensors)  can  be  gathered  and  processed  centrally.  But  for  the  most  part,  these 
decision  support  systems  are  to  be  fed  and  updated  at  the  local  Air  Operations  Center  level, 
based  on  on-site  information,  for  example,  the  prior  probability  of  the  event  of  interest  given  the 
local  conditions.  The  confidence  level  (“flag”)  required  before  further  action  must  be 
determined  by  the  commander. 

The  results  of  these  models  must  be  transparent,  comprehensible,  and  checkable  against  intuition 
to  verify  that  all  relevant  factors  that  the  human  mind  would  instinctively  (and  often  implicitly) 
account  for  are  included  in  the  computation.  The  benefits  of  these  support  systems  could  include 
faster  results,  fewer  people  involved  in  intelligence  processing,  enhanced  accuracy,  and 
provision  of  knowledge  rather  than  data. 

Probability  figures  cited  by  an  experienced  commander  as  an  illustration  of  an  informal  way  of 
doing  this  reasoning  seem  to  be  conservative  in  the  probabilities  rather  than  in  the  “flag”  used  for 
decision  making.  The  combination  of  probabilities  that  appear  conservative  and  of  a  threshold 
that  seems  low  permits  the  commander  to  determine,  in  the  end,  the  degree  of  risk  to  take.  The 
problem  is  that  conservatism  in  the  probabilistic  estimates  makes  it  difficult  to  maintain 
consistency  when  combining  information  from  different  sources.  It  is  more  logical  when 
computing  a  single  risk  figure  (to  be  compared  to  a  “flag”)  to  use  mean  probabilities  (for 
example,  mean  future  frequencies),  and  to  put  the  desired  conservatism  in  the  threshold  that 
triggers  the  “flag”  (that  is,  a  higher  threshold).  This  approach,  without  significantly  modifying 
the  reasoning,  would  allow  consistent  use  of  the  best  available  information  and  accurate 
combination  of  probabilities  while  preserving  the  desired  level  of  conservatism  in  the  decision. 
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Chapter  6 

Report  of  the  Acquisition  and  Program  Management  Panel 


6.1  Introduction 

The  Acquisition  Panel  examined  the  acquisition  process  to  acquire  and  evolve  command  and 
control  (C2)  systems  to  support  the  decision-makers  in  air  operations.  Our  particular  focus  was 
on  theater  C2  systems — such  as  the  Theater  Battle  Management  Core  System  (TBMCS) — 
acquisition  and  evolution.  We  took  the  following  approach  in  developing  our  findings  and 
rec  ommendations : 

1.  We  developed  a  list  of  desired  attributes  of  an  acquisition  process  for  C2  systems. 

2.  We  described  the  current  Air  Force  acquisition  process  for  C2  systems  (and  everything  else)  by 
doing  a  case  study  of  the  TBMCS  acquisition  as  a  normative  example. 

3.  We  searched  for  examples  of  other  acquisition  processes  that  might  better  satisfy  the  desired 
attributes  for  C2  systems. 

4.  We  formulated  our  findings  and  recommendations  for  modifying  the  current  Air  Force 
acquisition  process  for  C2  systems — especially  for  the  Theater  Aerospace  C2  System  (TACCS) — 
the  focus  of  this  study. 

We  detennined  that  an  evolutionary  integration  process  similar  to  the  one  used  by  the  Defense 
Information  Systems  Agency  (DISA)  in  evolving  the  Global  Command  and  Control  System 
(GCCS)  is  more  appropriate  than  what  we  have  used  in  the  past  for  acquiring  and  evolving  C2 
systems.  This  process  also  involves  evolutionary  development,  but  in  a  much  more  timely, 
diffuse,  and  distributed  way  than  it  has  been  done  in  the  past  in  the  Air  Force.  In  addition  to 
integration  and  development  process  changes,  we  agree  with  the  other  panels  that  major 
improvements  are  needed  in  institutional  focus  on  C2  in  the  Air  Force  (it  should  be  a  core 
competency),  in  advocacy  for  a  coherent  Air  Force  C  program  (we  need  an  Air  Force  Council 
Representative  addressing  C2  and  its  supporting  structures  alone),  in  funding  for  the  proper 
infrastructure  to  do  integration  of  new  capabilities  into  C2  systems  (a  program  element  [PE] 
funded  and  advocated  by  the  Air  Force  Materiel  Command  [AFMC]),  and  major  restructuring 
and  consolidation  of  program  elements  and  Air  Staff  panels. 

6.2  Approach  and  Visits 

The  first  meeting  of  the  summer  study  was  conducted  on  7  March  at  the  U.S.  Air  Force 
Academy.  This  was  a  panel-chair  kick-off  meeting  to  review  the  Terms  of  Reference.  On 
8  March,  the  Acquisition  Panel  Chainnan  met  with  the  General  Manager  of  Lockheed  Martin 
Colorado  Springs,  Mr.  Pete  Rogers,  to  discuss  the  TBMCS  program  and  general  acquisition 
approaches  for  such  programs. 

2 

The  next  meeting  was  the  Air  Force  C“  kick-off  meeting  at  Hurlburt  Field,  FL  on  20-21  March. 
The  panel  was  hosted  by  the  Air  Force  C“  Innovation  and  Training  Group  and  received  study 
guidance  from  the  Air  Force  C2  Study  Chainnan,  Dr.  Worch.  The  panel  also  received  briefings 
from  Maj  Gen  Perryman  (Commander,  the  Aerospace  Command  and  Control,  Intelligence, 
Surveillance,  and  Reconnaissance  Center  [AC2ISRC]),  Lt  Gen  Kenne  (Commander,  Electronic 
Systems  Center  [ESC])  and  BGen  Obering  (Assistant  Secretary  of  the  Air  Force,  Infonnation 
Dominance  [SAF/AQI]). 
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The  Acquisition  Panel  then  visited  ESC  3-5  April  for  an  infonnation-gathering  meeting. 

Lt  Gen  Kenne  hosted  the  panel  and  her  staff  provided  briefings  on  Global  Air  Traffic 
Management  System,  TBMCS,  Spiral  Development,  the  Joint  Surveillance  Target  Attack  System 
(JointSTARS),  Integrated  Space  Command  and  Control  (ISC")  program,  Joint  Expeditionary 
Force  Experiment  (JEFX),  Joint  Battlespace  InfoSphere  (JBI)  and  a  number  of  other  programs. 

The  entire  Air  Force  C2  study  then  convened  at  Langley  Air  Force  Base  (AFB)  on  10-11  April 
and  was  hosted  by  AC2ISRC.  Maj  Gen  Perryman  and  his  staff  provided  various  briefings  on 
Combat  Air  Force  (CAF)  C2  and  visitors  also  took  a  tour  of  the  Air  Combat  Command  Network 
Operations  Security  Center. 

The  next  infonnation  gathering  meeting  of  the  acquisition  panel  was  on  18-20  April  in 
Washington  DC.  Panel  members  met  with  Ms.  Darleen  Druyun  (Assistant  Secretary  of  the  Air 
Force,  Acquisition  [SAF/AQ]),  BGen  Gary  Salisbury  (DISA/D-6)  and  Mr.  John  Gilligan, 

(DOE/ Chief  Information  Officer  [CIO]),  who  was  previously  the  Program  Executive  Officer 
(PEO)  of  Battle  Management,  and  under  whose  aegis  the  integration  of  the  Contingency  Theater 
Automated  Planning  System  (CTAPS),  the  Wing  Command  and  Control  System  (WCCS),  and 
the  Combat  Intelligence  System  (CIS)  into  the  current  TBMCS  program  was  initiated. 

The  entire  Air  Force  Scientific  Advisory  Board  then  met  at  Nellis  AFB,  NV  for  the  Spring  Board 
Meeting  on  24-27  April.  The  Air  Force  C2  study  received  additional  briefings  from  ESC.  The 
panel  also  received  briefings  on  RED  FLAG  and  toured  the  RED  FLAG  facilities. 

On  28  April,  panel  members  traveled  to  Colorado  Springs  to  visit  Lockheed  Martin  concerning 
TBMCS  specifically.  The  panel  met  with  Mr.  Steve  McCulloch  and  Mr.  Reese  Delorey,  the 
initial  and  current  Lockheed  Martin  TBMCS  program  managers. 

Maj  Gen  Nelson  audited  major  portions  of  an  Anned  Forces  Communications  Electronics 
Association-sponsored  GCCS  course  in  Washington  DC  on  8-12  May  to  gain  further  insight  into 
the  current  GCCS  program. 

Panel  members  traveled  to  Washington  DC  on  16-18  May.  The  panel  met  with  the  following 
individuals  to  get  their  opinions  on  the  GCCS  integration  process  as  well  as  their  specific 
recommendations  on  the  acquisition  process  for  TACCS: 

•  DISA/D-6,  BGen  Salisbury 

•  Space  and  Naval  Warfare  System  Command  (SPAWAR),  Dr.  Frank  Perry 

•  SAF/AQI,  BGen  Obering 

•  Deputy  Chief  of  Staff,  Air  and  Space  Operations  (AF/SC),  BGen  Bell 

•  AF/XOC,  Maj  Gen  Hess 

•  AF/XOJ,  Maj  Gen  Baker 

•  AF/XOR,  Mr.  Disbrow 

•  AF/XPP,  BGen  McNabb 

The  Chairman  participated  in  a  Panel  Chairs’  meeting  at  Wobum,  MA  on  13-15  June. 

The  panel  returned  to  Washington  DC  on  26-27  Jun  to  meet  once  again  with  DISA — Ms.  Dawn 
Hartley;  Ballistic  Missile  Defense  Organization — Lt  Gen  Kadish;  SPAWAR — Dr.  Frank  Perry; 
and  the  Advance  Infonnation  Technology  Service  Joint  Program  Office  (JPO) — Mr.  Jim  Moody. 
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All  panel  members  participated  in  the  report  development  phase  at  San  Jose,  CA  10-21  July. 

The  Chairman  went  to  Wright-Patterson  AFB  on  7  August  to  collect  information  at  AFMC 
Headquarters  (HQ).  He  met  with  the  AFMC  commander,  Gen  Lyles,  and  Lt  Gen  Kenne  and 
Lt  Gen  Raggio,  commanders  of  ESC  and  Aeronautics  Systems  Center. 

6.3  Desired  Attributes  of  an  Acquisition  Process  for  C2  Systems 

The  process  defined  in  the  Department  of  Defense  Directive  (DoDD)  5000. 1  for  the 
acquisition24  of  major  systems  is  still,  even  in  the  current  revision,  slanted  toward  the  big  dollar 
hardware  systems  such  as  F-22 — and  that  is  probably  as  it  should  be.  But  there  is  a  major 
difference  between  these  big  hardware  systems  and  C2  systems — the  basic  technology  to  support 
system  implementation  is  evolving  at  a  much  higher  rate  for  the  latter.  And,  in  addition,  the 
ability  to  clearly  define  the  requirements  for  the  system  in  the  latter  case  is  much  more  difficult. 

It  is  really  true  that  the  operator  will  know  whether  or  not  he  likes  a  capability  of  a  largely 
software-based  C2  system  after  he  has  tried  it,  while  he  knows  even  before  a  prototype  is  built 
what  the  basic  capability  improvements  in  a  new  fighter  should  be.  Because  of  these  differences, 
the  assumption  that  one  acquisition  and  sustainment  process  should  serve  all  systems  is  an 
erroneous  one.  The  C  process  should  allow  much  more  operator  modification,  either  through 
improvements  made  by  the  operators  themselves  while  operating  real  systems,  or  through 
integration  of  new  capabilities  demonstrated  in  laboratories  or  such  activities  as  Advanced 
Concept  Technology  Demonstrations  (ACTDs)  and  JEFX.  Hence,  we  postulate  a  more 
appropriate  acquisition  approach  for  C  systems  in  general  as  one  that  has: 

•  The  interest  and  attention  of  senior  Air  Force  leadership 

•  A  planning,  programming,  and  budgeting  process  that  fosters  cohesion  of  the  components  (for 
example,  for  the  TACCS:  JointSTARS,  air  operations  center  [AOC],  Theater  Air  Control  System, 

25 

etc.)  and  continuity  of  development  for  appropriate  components 

•  A  development  and  evolution/integration  process  that: 

-  Allows  for  the  recognition  of  need  for  new  capability  during  system  operation 

-  Allows  for  the  rapid  integration  of  already  developed  and  tested  hardware  and  software  to 
satisfy  emerging  new  capability  requirements 

-  Allows  for  the  rapid  development,  testing,  and  integration  of  new  capabilities  when  and 
where  needed 

•  Fosters  continuous  communication  among  the  participants  in  the  acquisition — especially 
including  the  actual  users  (as  opposed  to  only  with  surrogates  for  them) 

•  An  organizational  structure  and  appropriate  resources  to  execute  the  PPBS  and 
development/evolution  processes 

23  DoDD  5000.1  still  describes  a  process  which  may  be  summarized  as:  collect  and  clearly  state  the  system’s 
requirements,  develop  and  test  a  system  implementation  that  satisfies  those  requirements,  do  an  independent 
operational  test  to  insure  that  the  operational  requirements  are  met,  field  the  system  and  sustain  it.  It  is  implied 
that  if  a  significant  increase  in  capability  is  required,  another  acquisition  cycle  is  needed. 

24  Acquisition  is  defined  as  development  and  procurement.  For  C2  systems  as  well  as  for  major  hardware  systems, 
there  is  a  subsequent  phase  called  sustainment — that  includes  evolution  of  the  system  (for  example,  block  changes 
for  airplanes),  but  for  C2  systems,  evolution  is  a  much  more  significant  activity  than  for  major  hardware  systems. 

25  “continuity  of  development”  means  avoiding  the  “big  bang  approach”  discussed  in  footnote  1  above — and  instead 
instituting  a  continuous  development  and  integration  process — much  like  we  define  sustainment  after  a  major 
system’s  initial  development  and  fielding. 
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•  Clear  definition  of  authority  and  responsibility  (for  example,  who  owns  the  concept  of  operations 
[CONOPS],  who  speaks  for  the  (joint)  users  in  defining  the  requirements,  who  directs  the 
contractors  involved,  who  makes  decisions  on  operational  suitability...) 

•  Development  and  integration  entities  primarily  motivated  by  the  success  of  their  efforts 

6.4  The  Current  Air  Force  Acquisition  Process  for  C2  Systems 
6.4.1  Acquisition  Management 

Based  on  the  recommendations  of  the  Packard  Commission  to  improve  the  Department  of 
Defense’s  (DoD’s)  organizational  arrangements  and  acquisition  management  procedures,  the 
Goldwater-Nichols  Reorganization  Act  was  made  a  public  law  in  1986.  The  recommendations 
centered  on  increasing  efficiency  and  effectiveness,  reducing  costs,  and  decreasing  acquisition 
cycle  times. 

The  Air  Force  implemented  the  Act,  similar  to  the  other  Services,  by  the  creation  of  a  Service 
Acquisition  Executive  (SAE),  PEOs,  and  program  managers  (PMs)  to  make  up  the  Acquisition 
Management  System.  The  statute  provided  a  new  Under  Secretary  of  Defense  (Acquisition)  to 
provide  overall  DoD  policy  for  procurement,  research,  and  development.  Most  noteworthy  was 
the  appointment  of  PEOs  to  be  responsible  for  a  reasonable  and  defined  number  of  acquisition 
programs.  The  PEOs  would  be  responsible  directly  to  the  SAE. 

In  the  reorganization,  the  former  Product  Center  and  Air  Logistics  Center  Commanders  were 
made  Designated  Acquisition  Commanders  (DACs)  and  were  to  provide  support  to  the  PEOs 
and  PMs.  The  DACs  would  be  decision  authorities  for  assigned  programs.  DoDD  5000. 2-R 
requires  assignment  of  program  responsibilities  to  PEOs  for  all  ACAT  I,  ACAT  IA,  sensitive 
classified  programs,  or  any  other  program  determined  by  the  SAE  to  require  dedicated  executive 
management.  DoDD  5000. 2-R  further  states  that  to  transition  from  a  PEO  to  a  commander  of  a 
systems  or  logistics  command,  a  program  shall  have  passed  Initial  Operating  Capability  (IOC), 
have  achieved  full-rate  production,  and  be  logistically  supportable  as  planned.  The  purpose  of 
these  changes  was  to  provide  stability  to  an  organizational  structure  and  make  arrangements  to 
place  highly  qualified  people  in  charge  of  programs  with  the  appropriate  authority  and 
responsibility.  Decentralized  execution  and  reduced  bureaucratic  layering  would  be  the  result. 

The  Air  Force  complied  with  DoD’s  guidance  and  Congressional  legislation  by  removing 
layered  procurement  decisions  and  unaccountable  acquisition  officials  from  the  Air  Force 
structure.  Major  programmatic  decision  authority  was  removed  from  AFMC.  Although  the  PMs 
now  have  a  higher  level  of  accountability,  these  streamlining  efforts  developed  a  process  of 
program  execution  that  is  complex,  interactive,  and  not  autonomous.  The  basic  question  is, 
“How  have  these  acquisition  reforms  increased  effectiveness  and  efficiency  of  the  Acquisition 
Management  System  where  actual  program  execution  takes  place?”  This  question  is  more 
difficult  because  there  are  no  metrics  to  measure  the  performance  of  the  reorganization. 

From  the  PEO  and  PM  perspective,  there  has  been  a  mixed  reaction  with  regard  to  the  results  of 
the  reorganization.  Results  are  highly  dependent  on  the  personalities  and  attitudes  of  the 
participants.  There  is  consensus  that  the  PM’s  decision-making  authority  has  been  enhanced. 
With  regard  to  acquisition  management  of  C"  systems,  the  assignment  of  portfolios  to  two  PEOs 
and  one  DAC  contributes  to  fragmentation  of  the  TACCS.  Previously,  some  C2  systems  were 
also  assigned  to  Air  Logistics  Center  Commander’s  (DACs)  portfolios.  These  programs  make 
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up  the  overall  TACCS,  but  are  not  assigned  to  a  specific  portfolio  for  management.  This  leads  to 
inconsistency  and  instability  of  the  overall  TACCS  program.  Further,  the  assignments  of  the 
PEOs  and  PMs  to  these  programs  have  been  shorter  than  the  reorganization  had  planned.  The 
Air  Force  has  not  controlled  the  reassignments  to  milestone  achievement  such  as  IOC,  full  rate 
production,  and  logistically  supported  systems. 

Another  goal  of  the  PEO  reorganization  was  to  force  system  integration  across  individual 
portfolios.  Since  the  original  portfolio  assignment,  the  importance  and  visibility  of  the  TACCS 
program  has  increased.  This  suggests  a  reassessment  be  made  to  include  all  those  programs 
within  TACCS  to  enhance  mission  area  integration.  There  are  currently  insufficient  resources 
within  each  program  element  that  makes  up  the  TACCS  program  for  overall  integration. 
Therefore,  the  PEO/DAC  portfolios  currently  miss  the  opportunity  for  commonality, 
interoperability,  and  standardization  across  the  C2  mission  area. 

6. 4. 1.1  Recommendations 

•  Establish  metrics  to  measure  the  effectiveness  of  the  PEO  management  system 

•  Stabilize  assignments  of  PEO/PMs  to  match  milestone  achievements 

•  Reassess  portfolio  assignment  of  programs  to  a  single  PEO/DAC  to  enhance  commonality, 
interoperability,  and  standardization 

6.4.2  The  Current  Air  Force  Acquisition  Process  for  C2  Systems:  A  Case  Study  of  TBMCS 
(abbreviated — full  text  in  Volume  2,  Appendix  6C) 

The  TBMCS  program  is  the  current  Air  Force  flagship  program  for  automating  and  integrating 
the  planning  and  execution  of  the  theater  air  war.  Its  five  core  functions  can  be  defined  as: 

•  Intelligence  collection  and  evaluation 

•  Planning 

•  Generating  and  distributing  the  Air  Tasking  Order  (ATO) 

•  Unit  level  scheduling  of  missions 

•  Monitoring  execution  of  the  ATO 

TBMCS  is  intended  to  link  these  intelligence,  planning,  and  operations  functions  through  the 
integration  of  several  legacy  systems  (or  their  equivalent  functional  capabilities),  the  most 
important  of  which  are  CIS,  CTAPS,  and  WCCS.  In  addition,  TBMCS  migrates  these  key 
theater  air  warfare  applications  to  the  Defense  Information  Infrastructure  Common  Operating 
Environment  (DII  COE)  platfonn.  The  complexity  of  this  integration  and  migration  was 
underestimated  in  the  mid-1990s  when  the  program  was  initiated  (as  have  been  most,  if  not  all, 
similar  integrations).  In  the  recent  words  of  the  then-PEO:  “It’s  the  most  difficult  program  I 
have  ever  encountered.” 

TBMCS  has  experienced  a  troubled  and  controversial  history  since  its  fonnal  launch  in  late 
1995,  when  Loral  (now  Lockheed  Martin  Mission  Systems  [LMMS]  of  Colorado  Springs)  won  a 
six-year  competitive  cost  plus  award  fee  contract  valued  around  $180  million.  The  program  has 
suffered  from  significant  schedule  slippage,  some  cost  growth,  and  major  performance  short 
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falls.  The  original  contract  envisioned  the  fielding  of  three  progressively  more  capable 
software  releases.  Instead,  as  of  June  2000,  the  program  still  had  not  been  able  to  successfully 
complete  and  field  Version  1.0.  In  addition,  the  current  Version  1.01  represents  a  significant 
down-scoping  in  the  capabilities  originally  envisioned  for  the  first  release.  As  a  result,  TBMCS 
is  now  widely  considered  to  have  been  a  seriously  flawed  program  with  regard  to  its 
development  process,  at  least  in  the  early  phases.  The  program  now,  however,  generally  seems 
to  be  on  track.  A  detailed  plan  for  the  fielding  and  future  upgrading  of  the  system  has  been 
developed. "  Nonetheless,  its  many  problems  in  its  early  phases  make  it  worth  examining 
carefully  for  “lessons  learned”  for  future  Air  Force  approaches  to  C2  systems  acquisition.  The 
following  is  a  list  of  lessons  learned  gleaned  from  extensive  interviews  with  the  key  Air  Force 

PEO,  PMs,  and  LMMS  senior  managers,  as  well  as  from  examination  of  numerous  program 

28 

office  documents  and  briefings." 

Lack  of  sufficiently  detailed  CONOPS,  system  architecture,  and  operational  requirements. 

TBMCS  was  launched  with  a  strong  visionary  high-level  CONOPS  and  system  architecture. 
However,  these  lacked  the  detail  necessary  to  provide  appropriate  guidance  to  the  Air  Force  and 
contractor  PMs  for  development  of  the  system.  No  formal  Operational  Requirements  Document 
was  ever  produced.  The  problem  was  compounded  by  the  lack  of  consensus  among  the  user 
communities  over  CONOPS  and  operational  requirements,  and  by  continual  change  and 
evolution.  The  constant  refrain  of  the  contractor  remained:  “Will  the  real  user  please  stand  up?” 

Lack  of  consistent,  strong  advocacy  leadership  in  the  highest  levels  of  the  Air  Force,  and  at 
the  System  Program  Office  (SPO)  and  contractor  levels.  Initially  TBMCS  had  a  few  strong 
advocates  in  the  highest  levels  of  the  Air  Force.  At  one  key  point  during  the  development  phase, 
an  Air  Force  Major,  far  down  in  the  SPO  hierarchy,  acted  as  the  de  facto  PM  for  nearly  a  year. 
The  program  lacked  clear  lines  of  authority  and  strong  leadership  both  on  the  government  side 
and  the  contractor  side. 

Inappropriate  application  of  current  acquisition  reform  (AR)  doctrines  of  transferring 
greater  system  definition  responsibility  to  the  contractor.  Partly  by  default,  and  partly 
because  of  DoD  AR  doctrine,  the  contractor  was  granted  significant  control  over  the 
development  of  the  system  operational  architecture,  configuration,  and  even  CONOPS.  The 
contractor  senior  management  lacked  the  operational  knowledge,  technical  skills,  and  initiative 
to  meet  this  challenge  effectively  without  greater  guidance  from  the  Air  Force.  Clear  guidance 
was  not  forthcoming. 

Use  of  a  “big  bang”  development  approach  instead  of  a  spiral  development  style  of 
approach,  which  delayed  fielding,  and  resulted  in  operator  pressure  to  divert  resources  to 
fixing  legacy  systems.  The  TBMCS  contract  called  for  the  development  and  fielding  of  three 
major  software  releases  over  a  six-year  period.  The  user  community  lobbied  hard  for  a  much 


26  The  original  contract  value  to  the  prime  contractor  was  $35  million  (excluding  fee,  zero  base  fee),  with  options 
that  were  eventually  exercised  amounting  to  $109  million,  resulting  in  a  total  of  $144  million.  Award  fees  and 
miscellaneous  changes  raised  this  to  $179  million.  A  category  labeled  “evolutionary  Requirements  (TTDs)” 
added  an  additional  $161  million,  for  a  total  contract  value  in  mid  2000  of  $327  million.  Mr.  Stephen  Kent,  ESC 
provided  this  information. 

~7  TBMCS  passed  its  Field  Demonstration  Test  in  June  2000.  An  MOT&E  was  accomplished  in  late  July. 

28  An  extensive  and  detailed  case  history  of  TBMCS  is  included  in  Appendix  6C  of  this  volume. 

29  CTAPS  and  WCCS  did  have  formal  System  Operational  Requirements  Documents. 
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quicker  fielding  of  initial  capabilities.  This  led  to  the  decision  to  divert  significant  resources  to 
fixing  existing  fielded  systems  (CTAPS,  CIS,  WCCS).  This  effort  proved  far  more  difficult  than 
anticipated,  leading  to  significant  delays  in  the  program,  because  the  fielded  legacy  systems  were 
seriously  flawed.  In  theory,  a  spiral  development  approach  could  have  led  to  a  much  earlier 
fielding  of  initial  capabilities,  thus  reducing  the  pressures  to  divert  resources  to  fixing  legacy 
systems. 

Insufficient  “jointness”  in  the  original  program  planning.  Failure  to  include  sufficient  joint 
vision  in  initial  program  planning  contributed  to  the  unanticipated  need  to  rehost  CTAPS  to 
Hewlett  Packard  and  SUN  servers  for  Navy  shipboard  operations.  This  was  identified  as  a  major 
unplanned  diversion  of  resources.  In  general,  Navy  requirements  and  needs  were  not  sufficiently 
recognized  in  the  early  phases  of  the  program. 

Underestimation  by  both  the  government  and  contractor  of  the  technical  difficulty  of 
integrating  legacy  systems.  Multiple  contractors  had  developed  the  legacy  software  modules, 
usually  in  conjunction  with  a  specific  lab  and  a  specific  user  command.  Thus  the  pieces  that 
would  make  up  TBMCS  had  no  unifonnity  in  architecture,  computer  language,  etc.  Little  formal 
documentation  existed,  resulting  in  difficulties  in  transferring  the  necessary  legacy  information 
to  LMMS.  This  problem  was  exacerbated  by  third  party  “associate”  contractors  that  had  no 
formal  contractual  relationship  with  LMMS.  Third,  some  particularly  troublesome  modules, 
such  as  Force  Level  Execution  (FLEX),  were  developed  by  labs  as  tech  demos,  and  were  not 
appropriate  for  fielding.  In  the  case  of  FLEX,  neither  the  SPO  nor  LMMS  had  direct  control 
over  development.  Finally,  virtually  all  the  legacy  modules  were  more  immature  technically 
than  originally  anticipated. 

Inadequate  process  for  controlling  and  screening  requirements/capabilities  development 
and  additions.  The  user  community  continued  to  develop  new  modules  and  capabilities  that 
were  folded  into  the  program.  No  process  existed  to  assess,  prioritize,  and  filter  these,  leading  to 
much  added  integration  work.  Little  discipline  was  exercised  over  requirements  growth  and 
change,  since  no  clear  baseline  configuration  was  ever  established  early  in  the  program. 

Lack  of  an  appropriate  strategy  for  testing  and  fielding  the  system.  The  program  did  not 
develop  a  consensus  on  a  unified  testing  concept  and  approach,  nor  on  test  metrics  forjudging 
success.  A  lack  of  a  unified  and  detailed  CONOPS  resulted  in  the  lack  of  a  standard  use  pattern 
by  users.  Different  testers,  with  different  use  patterns,  and  using  different  test  metrics,  conducted 
the  various  operational  and  fielding  tests,  producing  widely  varying  results.  This  was  a  major 
stumbling  block  to  fielding. 

6.5  Other  Acquisition  Approaches  for  C2  Systems 

In  the  time  allotted  for  collecting  data,  the  panel  was  not  able  to  do  an  exhaustive  study  of 
Government  and  commercial  approaches  to  acquiring  C2  or  C2-like  systems;  however,  the 
following  four  examples  are  worthy  of  note  for  their  acquisition  process  and  structure: 

•  DISA  acquisition  of  GCCS 

•  Navy  development  of  Global  Command  and  Control  System-Maritime  (GCCS-M), 

•  Air  Force  ISC2  Program 
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•  Department  of  Defense  Intelligence  Information  System  (DODIIS)  managed  by  the  Defense 
Intelligence  Agency  (DIA)  and  the  Air  Force. 

6.5.1  GCCS 

6.5.1.1  The  GCCS 

In  the  mid-1990s  DISA  instituted  a  process  for  evolving  GCCS.  It  replaced  the  mainframe- 
based  Worldwide  Military  Command  and  Control  System  with  a  more  capable  modern  system. 
The  process  follows  a  similar  process  put  in  place  by  SPAWAR  in  the  late- 1980s  when  that 
command  tried  to  come  to  grips  with  multiple  versions  of  several  stovepiped  C2  systems 
operating  in  the  Fleet.  GCCS  is  the  cornerstone  of  the  command,  control,  communications, 
computers,  and  intelligence  (C4I)  for  the  warrior  and  addresses  the  mission  need  statement  for 
GCCS,  8  June  1995.  GCCS,  as  a  warfighter-oriented  system,  provides  improved  information 
processing  support  in  the  areas  of  planning,  mobility,  and  sustainment  to  combatant 
commanders,  the  Services,  and  Defense  agencies.  GCCS  consists  of  all  necessary  hardware, 
software,  procedures,  standards,  and  interfaces  for  connectivity  worldwide  at  all  levels  of 
command;  and  supports  and  integrates  a  wide  assortment  of  mission  critical,  inter-Service, 
Service,  and  site-unique  applications,  databases  and  office  automation  tools.  It  provides  an  open 
system  infrastructure  that  allows  a  diverse  group  of  systems  and  commercial-off-the-shelf 
(COTS)  software  packages  to  operate  at  any  GCCS  location  with  a  consistent  look  and  feel. 
GCCS  users  can  readily  access  web-enabled  applications  and  databases.  The  functional  groups 
within  GCCS  are  situational  awareness,  force  planning,  and  office  automation  and  messaging. 
GCCS  has  been  characterized  as  a  non-near-real-time  system,  but  recent  application  integrations 
have  brought  it  closer  to  dealing  with  the  near-real-time  environment. 

6.5. 1.2  DISA  and  GCCS  Evolution 

DISA’s  process  to  evolve  GCCS  is  closer  to  a  sustainment  than  a  development  process.  It 
recognizes  the  rapid  evolution  of  software,  computer  hardware,  and  communications 
technologies  and  seeks  to  save  time  and  money  by  integrating  capabilities  (applications)  into  the 
GCCS  after  those  applications  have  been  developed  in  prototype  form  and  found  operationally 
useful  through  ACTDs,  exercises,  etc.  This  approach  reverses,  in  a  sense,  the  classical 
acquisition  approach,  which  does  operational  testing  after  the  major  and  costly  work  of 
requirements  collection,  development,  and  integration  have  been  accomplished.  (There  will 
often  have  been  a  prototype  developed  and  tested  before  the  classical  acquisition  process  is  even 
started).  The  process  depends  on  the  applications  having  been  developed,  frequently  over  a  few- 
year  period,  to  be  compliant  with  a  supporting  structure,  or  platform — in  this  case  the  DII  COE. 
While  an  application  may  have  taken  years  to  develop  and  operationally  test,  the  process  of 
integration  and  fielding  typically  is  done  within  two  to  three  months. 

The  Joint  Information  Engineering  Organization  (JIEO)  manages  the  evolution  of  the  GCCS  and 
the  evolution  of  the  COE.  The  DISA  D6  is  normally  the  Commander  of  this  organization.  There 
is  no  grand  design  or  master  set  of  requirements  against  which  the  system  is  evolved,  rather — 
there  is  a  new  requirement  identification  and  prioritizing  process  accomplished  annually.  The 
commanders  in  chiefs  (CINCs),  Services,  and  Agencies  identify  and  validate  requirements  for 
new  capabilities  to  be  integrated  into  GCCS.  Applications  addressing  those  requirements  are 
typically  validated  operationally  in  exercises,  ACTDs,  and  the  like — and  have  been  developed  in 
compliance  with  the  COE  (typically  at  level  7).  A  series  of  functional  working  groups  overseen 
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by  the  Joint  Staff  J3  (recall,  the  GCCS  is  the  CINCs’  C  system)  ranks  those  requirements,  as  the 
JIEO  has  essentially  a  level-funded  budget  each  year  and  hence  integration  of  all  requirements 
cannot  be  accommodated. 

Using  primarily  a  set  of  facilities  in  the  DC  area  (a  principal  one  being  the  Operational  Support 
Facility),  the  JIEO  and  its  contractors  integrate  the  COE-compliant  applications  which  have  been 
approved  into  the  GCCS  and  distribute  new  software  to  well  over  a  hundred  sites  worldwide. 

This  integration  typically  takes  a  few  months  for  each  application,  even  though  the  development 
and  operational  test  of  an  application  may  have  taken  a  few  years.  Applications  are  fielded 
continually,  usually  a  few  per  month.  The  integration  cycle  is  shown  graphically  in  Appendix 
6D  of  this  volume,  and  a  recent  schedule  for  applications  fielding  is  in  Appendix  6E.  A  list  of  all 
applications  and  their  descriptions  is  at  Appendix  6F.  To  execute  this  GCCS  integration  process, 
the  JIEO  has  a  budget  of  approximately  $60+  million  annually  (PE  0303 150K),  mostly 
operations  and  maintenance  (O&M)  (some  procurement),  and  mostly  for  contractors  and 
facilities.  There  are  also  approximately  200  government  personnel  (mostly  Civil  Service)  funded 
in  other  lines.  For  DII  COE  maintenance  and  evolution,  DISA  D6  uses  approximately  $25 
million  annually,  mostly  for  contractors  and  facilities,  along  with  40-50  government  personnel 
(mostly  Civil  Service).  Supporting  the  whole  effort  are  a  number  of  other  facilities  and 
organizations,  such  as  the  JPO  (the  Defense  Advanced  Research  Projects  Agency/DISA),  which 
facilitates  development  and  ACTD  transition  (approximately  $25  million  annually,  including 
approximately  50  contractors,  facilities,  and  about  20  government  personnel),  and  the  Joint 
Development  and  Evaluation  Facility  (a  mini  CINC  HQ),  assigned  to  DISA  D8.  There  are  other 
facilities  and  participants  as  well.  Procurement  and  sustainment  funding  is  the  responsibility  of 
the  individual  CINCs. 

6.5.2  SPA  WAR  and  GCCS-M  Evolution 

It  is  important  to  understand  the  Navy  structure  for  defining  requirements  and  developing  and 
acquiring  C2  systems.  C2  requirements  stem  from  fleet  originated  needs  and  are  forwarded  to  the 
Chief  of  Naval  Operations,  specifically  the  Director  of  Space,  Information  Warfare,  Command, 
and  Control,  N-6.30  These  requirements  are  refined  and  become  part  of  a  balanced  budget 
process,  meaning  that  C  items  are  balanced  against  all  other  needs,  including  ships,  aircraft  or 
personnel,  at  the  Office  of  the  Chief  of  Naval  Operations  level.  The  requirements  and  the 
necessary  resources  are  then  passed  to  one  of  the  Navy  System  Commands  or  a  PEO  for 
development  and  acquisition.  Figure  6-1  graphically  captures  the  essence  of  this  centralized 
process. 

The  SPAWAR  philosophy  that  has  been  used  in  acquiring  and  evolving  GCCS-M  is  essentially 
the  same  as  DISA’s  process  in  evolving  GCCS.  This  is  not  surprising  given  that  RADM  John 
Gauss,  who  now  commands  SPAWAR,  and  Dr.  Frank  Perry,  his  Technical  Director,  created  the 
DISA  D-6  structure  during  their  tenure  in  DISA  and  had  defined  the  SPAWAR  process  several 
years  earlier.  RADM  Gauss  was  the  SPAWAR  Program  Manager  for  what  was  then  the  Joint 

Operational  Tactical  System  (JOTS)  system.  As  program  manager,  Gauss’s  job  was  to  bring 

2 

JOTS  under  configuration  control.  He  additionally  realized  that  the  many  other  stovepiped  C 


30  Although  some  other  Navy  organizations  have  some  involvement  in  C4,  N-6  is  clearly  the  central  point  of  focus 
and  spokesperson  within  the  Navy  for  these  matters. 

31  JOTS,  variously  the  Joint  Operational  Tactical  System  or  the  Jerry  O.  Tuttle  System,  an  early  fleet  inspired  and 
deployed  C2  system  which  was  well  accepted  but  not  under  adequate  configuration  control. 
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systems,  each  with  distinct  software,  operating  systems,  and  databases  were  costly  to  maintain 
and  needed  to  be  brought  into  a  common  system  or  retired.  The  process  chosen  was  the 
beginning  of  the  process  now  used  for  both  GCCS  and  GCCS-M.  In  its  very  essence,  that 
process  is  to  define  a  COE  and  specify  standards  and  a  process  for  implementing  applications 
that  will  run  on  this  COE.  This  process  is  described  in  Appendix  6G  of  this  volume. 


Allocate  resources  to 
provide  best  mix  of  forces, 
materiel ,  and  support  within 
fiscal  constraints 


SECNAV 
CNO  and  CMC 


Identify  current 
and  future  mission 
needs  that  require 
solutions 


Manage 

development  and 
acquisition  of  new 
items  and 
upgrades 


Effective  Integration  among  processes  is  imperative 


Figure  6-1 .  Major  Decision-Making  Support  Processes  in  the  Department  of  the  Navy 


Candidate  applications  for  use  on  GCCS-M  are  frequently  first  demonstrated  in  naval  exercises 
and  then  integrated  into  GCCS-M.  SPAWAR  has  fonned  a  strategic  alliance  with  the  Naval 
Warfare  Development  Command  and  has  participated  with  them  in  Fleet  Battle  Experiments. 
Important  thrusts  like  Time  Critical  Strike  have  found  a  pre-determined  pathway  through 
experimentation  and  prototyping  to  production  deployment.  Most  of  the  development  and 
integration  work  is  done  at  two  major  SPAWAR  field  activities  in  Charleston  and  San  Diego. 
The  annual  funding,  including  contractor  support,  is  approximately  $30  million  RDT&E, 

$30  million  O&M,  and  $120  million  procurement.  In  addition,  there  are  approximately 
34  people  in  the  HQ  office  for  GCCS-M  who  are  funded  out  of  the  HQ  personnel  resources. 

The  GCCS-M  program  is  at  the  ACAT  II  level.  Fleet  Commanders  supplement  the  procurement 
funds  by  buying  additional  PC’s  and  LAN  backbones  that  SPAWAR  installs.  Under  the 
Information  Technology-21  (IT-21)  concept,  SPAWAR  is  able  to  upgrade  four  Battle  Groups 
or  Amphibious  Ready  Groups  each  year  with  current  versions  of  GCCS-M  and  concomitant 
hardware  and  supporting  software.  Grouping  the  fleet  by  Battle  Groups,  Amphibious  Ready 
Groups,  or  Fleet  Flagships  yields  29  major  afloat  IT-21  installations  including  GCCS-M.  ” 


,2  IT-21  is  a  Navy  plan  to  up-date  the  information  technology  capability  of  each  deploying  Battle  Group  so  that  each 
ship  in  the  Battle  Group  is  raised  to  a  common  level  of  hardware  and  software  for  information  technology. 

”  The  29  consist  of  12  Carrier  Battle  Groups,  12  Amphibious  Ready  Groups  and  five  flagships  supporting 
numbered  fleet  commanders.  One  of  the  five  flagships  is  in  reality  a  command  center  in  Bahrain  supporting  the 
Naval  Component  Commander  in  the  Central  Command. 
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Commonality  between  GCCS  and  GCCS-M  is  estimated  at  95  percent.  GCCS-M  constitutes 
lA  -  %  of  each  Battle  Group’s  C2  capability,  not  considering  the  combat  direction  capability  of 
the  ship. 

6.5.3  Air  Force  Space  Command  (AFSPACECOM)  and  the  ISC2  Effort 

The  ISC'  Program  is  being  managed  through  a  PEO,  using  ESC  resources  in  the  Strategic  and 
Nuclear  Deterrence  C  SPO.  Most  of  its  few  hundred  people  physically  located  in  Colorado 
Springs,  collocated  with  the  Operating  Command  (AFSPACECOM);  the  remainder  are  at  ESC. 
The  SPO  is  charged  with  awarding  a  contract  mid-2000  for  a  long-tenn  (15  year)  alliance  with  a 
single  contractor.  The  contractor  will  assume  Total  System  Performance  Responsibility  (TSPR) 
to  evolve  from  the  current  North  American  Air  Defense  Command  (NORAD)  U.S.  Space 
Command  (USSPACECOM)  Warfighting  Support  System  (N/UWSS)  to  a  target  operational  and 
system  architecture  that  is  being  developed  as  part  of  the  contractor  downselect.  The  plan  is  that 
the  effort  will  be  level-funded,  at  the  total  level  of  the  currently  existing  systems,  which  provide 
the  as-is  capability  (approximately  $100  million  total  annually  in  various  appropriations, 
RDT&E,  procurement,  and  O&M).  DII  COE  compliance  is  required. 

2  2* 

ISC  efforts.  ISC"  work  will  be  concentrated  in  the  following  areas: 

•  Sustainment  of  new  and  existing  ISC2  systems 

•  Migration  of  existing  ISC2  systems  to  a  common  integrated  architecture 

•  New  C2  capability  development  and  fielding  in  a  common  integrated  ISC2architecture 

•  Achieving  interoperability  and  collaboration  among  ISC2operation  centers 

•  Enabling  and  performing  external  integration  of  the  ISC2systems  with  Air  Force,  DoD,  and  other 
interfacing  systems  with  emphasis  on  operation  center/node  interoperability 

•  Organizational  level  maintenance  of  ISC2systems 

ISC2  contract.  The  ISC2  contract  will  address  USSPACECOM,  NORAD  and  their  component’s 
ballistic  missile/C2  and  related  requirements  (for  example,  N/UWSS).  This  includes  both 
existing  requirements,  as  well  as  those  needs,  like  Information  Operations,  Shared  Early 
Warning  and  Space  Battle  Management  and  Control  emerging  during  the  contract  period  of 
performance.  The  contract  scope  will  also  include  system  development,  modification, 
integration,  and  support  for  other  organizations  with  related  missions  (for  example,  U.S. 

Strategic  Command’s  [USSTRATCOM’s]  Mobile  Consolidated  Command  Center  needs).  The 
ISC2  contract  will  evolve  the  as-is  system  to  eliminate  or  mitigate  the  current  system’s 
shortcomings.34 

A  major  objective  is  to  create  a  long-term  Government/Contractor  partnership  with  the 
contractor  realizing  a  sense  of  program  ownership  and  allow  the  Government  to  reduce  the  size 
of  the  SPO.  The  contractor  will  manage  and  facilitate  integration  with  systems  outside  the  ISC2 
contract  and  establish  a  comprehensive  and  integrated  training  program  for  the  lifecycle  of  all 
systems  within  the  ISC2  contract.  They  will  provide  SPO  level  integration,  systems  engineering, 
and  test  support  across  SPO  programs.  The  minimum  functions  the  ISC2  contractor  must  cover 
include: 

•  Requirements  impact  analysis,  coordination,  and  allocation 


34  N/UWSS  Capstone  Requirements  Document,  dated  21  February  1999. 
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•  Integrated  cross-SPO  architecture  activities 

•  Configuration  management  activities 

•  System-of-systems  level  enterprise  information  system 

•  Integrated  scheduling 

•  Integration  issue  identification,  tracking,  and  resolution 

•  Logistics  planning  for  architecture  evolution 

The  ISC2  approach  is  different  in  some  key  ways  from  the  DISA  GCCS  and  SPAWAR  GCCS-M 
activities.  The  main  differences: 

•  The  Air  Force  seeks  to  assign  TSPR  to  the  contractor  on  ISC2,  while  the  GCCS  and  GCCS-M 
efforts  explicitly  reserve  it  to  the  Government 

•  The  Air  Force  seeks  to  reduce  people  resources  required  to  manage  a  C2  program  by  assigning 
most  of  the  program  management  responsibilities  to  the  contractor 

•  There  is  a  target  operational  and  system  architecture  specified  at  the  outset  of  the 

Air  Force/contractor  alliance  which  requires  an  evolution  plan  to  reach  the  goal  from  the  as-is 
state.  This  feature  is  not  in  the  GCCS  nor  GCCS-M  programs 

•  ISC2  is  built  on  the  DII  COE  as  a  main  foundation — but  not  explicitly  on  GCCS.  It  must 
interoperate  with  GCCS,  TBMCS,  and  USSTRATCOM 

2 

The  other  major  difference  is  that  the  ISC"  approach  is  yet  to  be  evaluated,  while  the  GCCS 
approach  has  been  in  operation  for  at  least  a  few  years.  There  are  at  least  three  similarities 
between  the  ISC2  and  GCCS/GCCS-M  approach: 

•  Both  assume  a  level  of  effort  on  a  relatively  long-term  program  to  evolve  the  C2  capability — this 
is  a  new  approach  for  the  Air  Force  acquisition  structure 

•  Both  evolve  through  integration  of  developed  and  operationally  proven  applications 

•  Both  depend  on  a  cooperative  enterprise  among  user,  acquirer,  tester,  and  contractor 

6.5.4  Department  of  Defense  Intelligence  Information  System 

The  DODIIS  architecture  is  managed  by  DIA  and  incorporates  intelligence  collection, 
processing,  exploitation,  and  dissemination  mission  applications  all  existing  in  a  common 
computing  infrastructure.  Individual  applications  are  produced  and  maintained  by  the  individual 
Services  and  various  Combat  Support  Agencies  (DIA,  National  Imagery  and  Mapping  Agency 
[NIMA],  and  National  Security  Agency  [NSA]).  The  DODIIS  integration  and  testing  process  is 
very  similar  to  the  GCCS  approach  and  has  been  in  place  for  over  five  years.  In  addition  to 
leading  the  technical  development  for  the  DODIIS  infrastructure  transition  to  DII  COE,  Deputy 
Chief  of  Staff,  Air  and  Space  Operations,  Intelligence,  Surveillance,  and  Reconnaissance 
(AF/XOI)  manages  the  life-cycle  development  of  several  intelligence  mission  applications  (via 
ESC/IC  and  Air  Force  Research  Laboratory  (AFRL),  Information  Directorate  (AFRL/IF) 
procurements)  and  is  also  the  Executive  Agent  for  DODIIS  integration  and  test.  The  Air  Force 
coordinates  all  responsible  test  agency  involvement,  including  the  Joint  Interoperability  Test 
Center  for  interoperability  testing,  AFRL  Joint  Integration  and  Test  Facility  (JITF)  for 
integration  testing,  DIA  for  security  certification,  and  the  appropriate  agency  or  Service  training 
certification.  The  JITF  at  AFRL/IF  conducts  integration  testing  to  ensure  each  release  of  a 
DODIIS  product  meets  the  infrastructure  requirements.  Results  of  DODIIS  testing/certification 
activities  are  reported  to  the  DODIIS  Management  Board  (DMB)  via  attachments  to  an 
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Acquisition  Decision  Memorandum.  The  DMB  approves/disapproves  deployment  of  individual 
products  based  on  this  input. 

DODIIS  implementation.  All  AF/XOI-managed  DODIIS  software  programs  utilize  a  spiral 
development  process;  examples  include  the  Communications  Support  Processor  (CSP), 
Information  Support  Server  Environment  (ISSE)  Guard  and  PROJECT  BROADSWORD.  Each 
of  these  products  have  been  successfully  exported  from  the  intelligence  community  to  the  Air 
Force  C  community  after  incorporating  C~-specific  requirements  via  “spirals.”  The  GCCS-like 
DODIIS  integration  and  testing  process  lends  itself  particularly  well  to  spiral  development  due  to 
parallel  conduct  of  various  test  and  certification  activities  and  the  less  than  60-day  integration 
certification  timeline.  The  GCCS  and  DODIIS  integration  and  test  model  focus  on  relaying 
specific  infrastructure  requirements  to  the  developing  program  office  early  in  the  development 
process  and  assessing  an  individual  product’s  evolving  compliance  towards  these  standards  over 
its  life  cycle.  Critical  to  the  success  of  the  GCCS  and  DODIIS  models  is  the  presence  of  a 
Management  Board  to  decide  deployment  readiness.  The  GCCS  and  DODIIS  models  place 
more  of  the  program  management  responsibility  for  scheduling,  integration,  and  configuration 
management  on  the  Government. 

6.6  Oversight 

Background.  The  AC2ISRC  charter,  dated  4  December  1998,  ascribes  certain  Air  Staff  like 
functions  to  the  AC2ISRC.  Examples  include  the  following  mission  statement  excerpts: 

“AC2ISRC  serves  as  the  lead  organization  to  integrate  and  influence  C"  and  intelligence, 
surveillance,  and  reconnaissance  (ISR)  for  the  Air  Force.  Primary  tasks  are  to: 

•  Integrate  air  and  space  command  and  control,  intelligence,  surveillance,  and  reconnaissance 
operational  and  delegated  systems  architectures,  roadmaps,  requirements  and  standards  in  a 
continuing  drive  toward  commonality,  maximizing  efficiency  and  reducing  duplication  of  effort. 

•  Build  aerospace  C2  and  ISR  modernization  strategies,  integrated  mission  area  plans  (MAPs), 
investment  plans/divestment  strategies,  appropriate  C4I  support  plans,  and  associated 
programming  documents  that  ensure  Air  Force  C2  and  ISR  will  meet  the  challenges  of  Global 
Engagement  and  Joint  Vision  2010  and  beyond. 

•  Ensure  roadmaps,  requirements,  and  the  operational  and  delegated  systems  architectures  are 
linked  to  the  current  Air  Force  Modernization  Planning  Process,  the  Air  Force  Strategic  Plan,  and 
Thrust  Area  Transformation  Plans,  or  their  future  evolutions.” 

In  addition,  among  the  Center’s  responsibilities  delineated  in  this  same  charter  are: 

•  “Architectures.  AC2ISRC  will  develop  and  maintain  near  term  and  long-term  C2  and  ISR 
operational  architectures  for  the  Deputy  Chief  of  Staff,  Air  and  Space  Operations  (AF/XO),  to 
include  baselining  Air  Force  fixed  and  deployable  command  centers.  AC2ISRC  will  integrate 
major  command  (MAJCOM)/field  operating  agency  (FOA)  inputs  in  the  design  and  management 
of  the  C2  and  ISR  system-of-systems  architecture  in  conjunction  with  the  acquisition  community. 
Operational  architectures  will  be  developed  in  accordance  with  the  DoD  command,  control, 
communication,  computer,  intelligence,  surveillance,  and  reconnaissance  (C4ISR)  Architecture 
Framework  document.” 

•  “Strategic  planning.  AC2ISRC  will  lead  the  Air  Force  C2  and  ISR  mission  area  planning 
processes,  and  produce  the  associated  C2  MAPs,  ISR  MAPs,  an  integrated  C2  and  ISR  roadmap, 
and  other  planning  documents,  to  include  C2  and  ISR  investment  plans/divestment  strategies. 
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AC2ISRC  will  coordinate  on  all  Air  Force  C4I  Support  Plans  and,  when  appropriate,  lead  the 
development  of  C41  Support  Plans.  AC2ISRC  will  ensure  C41  Support  Plans  are  complied  with, 
especially  in  the  area  of  interoperability  and  bandwidth  and  frequency  spectrum  utilization. 
AC2ISRC  will  ensure  all  Air  Force  C2  and  ISR  acquisitions  conform  to  interoperability  standards 
required  for  joint  certification.  AC21SRC  will  also  establish  liaison  with  D1A,  the  National 
Reconnaissance  Office,  NSA  and  NIMA  to  accomplish  cooperative  planning.” 

•  “Program  Objective  Memorandum  (POM)  responsibilities.  AC2ISRC  will  build  and  submit 
an  integrated  POM  for  aerospace  C2  and  ISR  forces  with  MAJCOM/FOA  input  and  coordination. 
To  accomplish  this,  AC2ISRC  will: 

-  Develop  a  strategic/long  range  vision,  a  C2  and  ISR  roadmap  and  an  investment 
plan/divestment  strategy,  and  serve  as  the  MAJCOM/FOAs’  primary  advocate  for  C2  and 
ISR. 

-  Build  an  integrated  POM  that  reflects  the  roadmap  and  investment  plan/divestment  strategy, 
and  assess  MAJCOM/FOA  compliance  with  the  roadmap.  All  interested  Air  Force  C2  and 
ISR  parties  will  be  included  in  a  deliberative,  collaborative  board  structure  for  building  the 
POM  input.  In  the  event  of  disagreement,  all  parties  will  attempt  to  reconcile  differences 
between  the  MAJCOM  POM  and  the  integrated  POM  before  submission  to  the  Air  Staff.  In 
all  cases,  AC2ISRC  will  submit  an  integrated  POM  recommendation  that  meets  HQ  Air 
Force  guidance.  AC2ISRC  will  also  include  with  this  POM  a  C2  and  ISR  update  that  will 
include  the  status  of  each  program  and  a  reconciliation  between  the  C2  and  ISR  roadmap  and 
each  C2  and  ISR  program. 

-  Review  and  provide  recommended  Air  Force  input  to  planning  and  programming  guidance 
documents  for  the  intelligence  community.  These  include  the  Joint  Intelligence  Guidance  for 
National  Foreign  Intelligence  Program,  the  Joint  Military  Intelligence  Program,  and  the 
Tactical  Intelligence  and  Related  Activities  aggregation;  the  Program  Manager’s  Guidance 
for  the  General  Defense  Intelligence  Program;  and  any  other  pertinent  documentation  which 
may  be  issued  by  the  Office  of  the  Secretary  of  Defense  (OSD)  or  national  intelligence 
program  managers.  Through  these  reviews  and  comments,  ensure  that  Air  Force  programs 
and  capabilities  continue  to  be  interoperable  with  national  capabilities  and  in  compliance  with 
national-level  architectures  and  standards. 

-  In  conjunction  with  the  appropriate  Air  Force  component,  assess  the  ability  of  aerospace  C2 
and  ISR  POM  submissions  to  meet  the  CINCs’  identified  needs  and  priorities.  AC2ISRC 
will  synchronize  Air  Force  C2  and  ISR  programs  with  Joint  warfighting  requirements  to  the 
maximum  extent  possible. 

-  Maintain  visibility  of  the  execution  and  budget  years. 

-  When  requested,  attend  meetings  of  the  Air  Force  Planning  Board  of  Directors,  and  serve  as 
an  advisor  to  the  Air  Force  Board  and  Council.” 

Discussion.  In  executing  its  POM  responsibility  the  Center  functions  almost  exactly  as  the  Air 
Staff  Panel  Structure  in  that  MAJCOM  inputs  are  received,  reviewed,  and  integrated  with  other 
MAJCOM  inputs;  measured  against  a  funding  level;  and  then  submitted  as  a  balanced  program, 
recommending  funding  levels  for  O&M  and  modernization.  It  is  not,  however,  treated  as  such 
by  the  Air  Staff,  which  receives  the  input  and  then  refers  it  to  the  usual  Panel/Board  Structure  for 
dissection.  These  panels  have  important  responsibilities,  but  an  integrated  C2  system  is  not 
among  them. 

The  POM  structure  is  the  foundation  on  which  the  Integrated  C  System  is  built.  Recent  events, 
most  noticeably  the  2002  POM  submission,  indicate  that  the  current  Air  Force  structure,  as  noted 
above,  is  not  conducive  to  supporting  or  modernizing  our  C  structure.  AC2ISRC  POM  input, 
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generally  praised  as  a  balanced,  well  thought  out,  integrated  effort,  was  basically  altered  at  Air 
Force  level.  Suggested  offsets  were  taken,  but  not  used  to  source  other  C2  elements.  The 
AC2ISRC  budget  was  downsized  by  approximately  6  percent  in  an  era  where  infonnation 
management  technology  has  been  demonstrated  to  be  a  force  multiplier  in  both  military  and 
commercial  enterprises.  While  this  paper  is  not  to  suggest  that  AC2ISRC  should  be  immune 
from  review,  it  does  suggest  that  the  AC2ISRC  needs  a  senior  champion  on  the  Air  Staff  to 
assure  C2  receives  due  consideration  in  the  Air  Force  priority  schema. 


A  look  at  the  Navy  Staff  is  instructive  here.  The  Navy  C2  organization  is  centered  on  the  Chief  of 
Naval  Operations,  N-6.  This  position  is  normally  a  three  star  flag  officer,  however,  at  this  time, 
a  two  star  officer,  RADM  Dick  Mayo,  fills  it.  The  N-6  is  responsible  for  setting  C2  requirements 
and  providing  the  funding  necessary  to  support  the  required  research  and  development, 
procurement,  and  O&M  funds  to  support  communication,  information  warfare,  and  C2  programs. 
The  requirements  for  these  programs  are  initiated  by  and  provided  to  N-6  by  the  Fleet  CINCs. 

N-6  makes  the  initial  attempt  to  balance  any  disparities  into  an  equitable  program,  which  is  then 
presented  to  N-8  for  evaluation  and  balance  with  all  other  Navy  program  areas.  After  the  budget 
for  Navy  C2  is  determined,  the  funds  are  provided  to  the  commands  which  will  be  responsible  for 
procuring  the  required  systems  or  making  the  required  modifications/modernization. 
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Figure  6-2.  Navy  C2  Organization 
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As  shown  in  Figure  6-2,  the  Navy  C"  system  is  more  closely  aligned  with  development/ 
acquisition  responsibilities  and  Navy  staff.  Recent  Navy  studies  have  called  for  an  even  stronger 
and  higher  level  organization  to  oversee  C  ,  suggesting  the  creation  of  a  functional  commander 
for  operations  information  and  space  command.  This  officer  would  report  to  the  Three  Fleet 
Commanders,  in  the  same  manner  that  the  current  platform  commanders  report. 

The  Navy  model  described  above,  suggests  the  creation  of  a  command,  control,  and 
communications  “Czar”  for  the  Air  Force.  This  individual  would  be  the  focal  point  for  C2  on  the 
Air  Staff  and  assure  that  C  has  the  appropriate  priority  in  the  Air  Force  budget.  A  further  and 
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necessary  function  of  the  command  control  and  communications  “Czar”  would  be  to  assure  that 
the  Command  (CAF,  SPACECOM,  USSTRATCOM,  Air  Mobility  Command)  and  functional 
(logistics,  personnel,  medical,  finance)  C2  systems  do  not  become  (or  continue  to  be) 
individually  and  collectively  stovepiped  but  move  toward  appropriate  levels  of  integration. 

These  are  not  trivial  issues  and  must  be  addressed  at  Air  Staff  level.  Since  solutions  to  C2  issues 
have  proved  to  be  elusive  to  date,  a  presence  on  the  Air  Force  Council  seems  mandatory. 

We  have  considered  several  alternatives  to  source  and  place  this  position: 

•  Create  a  new  three  star  position  for  C2.  This  provides  the  positive  attributes  of  unity  of  purpose, 
right  level,  show  of  resolve  to  attack  the  C2  issue.  It  would  require  creation  of  an  additional  three 
star  billet  in  the  Air  Force  or  elimination  of  a  field  three  star  position  and  movement  to 
headquarters. 

•  Add  C2  czar  duties  to  the  Air  Force  CIO  position.  This  shows  high  level  resolve  but  the  CIO  is 
currently  a  SAF/AQ  additional  duty.  The  incumbent  is  not  and  would  not  be  an  operator  or  a 
member  of  the  Air  Staff  Council. 

•  Add  the  task  to  AF/XO.  Again,  this  would  be  an  additional  duty  but  would  show  resolve  and 
could  be  staffed  by  an  operator.  It  is  not  at  the  correct  level,  as  it  would  undoubtedly  be 
delegated  below  three  star  level. 

•  Use  the  current  AF/SC  3-star  billet  to  create  a  new  position  on  the  Air  Staff  (with  Council 
membership)  for  C3.  Move  appropriate  3-letters  (for  example,  AF/XOI,  AF/XOC)  under  this 
Deputy  Chief  of  Staff  (DCS).  Leave  appropriate  AF/SC  three-letters  in  the  DCS.  Staff  with 
operators  with  C2  experience.  This  provides  close  to  unity  of  purpose,  is  at  the  correct  level, 
shows  resolve,  allows  an  operationally  oriented  incumbent,  and  utilizes  an  existing  billet  already 
in  HQ  Air  Force.  It  eliminates  the  emphasis  on  communications  and  networks  which  was 
deemed  appropriate  some  time  ago. 

Findings.  The  C  system,  to  attain  its  potential  as  a  force  multiplier  and  provide  flexible, 
deployable  capability  to  CINCs  and  Air  Component  Commanders,  requires  a  well-constructed 
modernization  program  that  is  sustained  over  time.  To  this  end,  a  senior  level  advocate  is  needed 
at  Air  Force  level  to  champion  C  as  a  priority  among  the  other  Air  Force  requirements.  The 
incumbent  would  use  the  AC2ISRC  as  a  primary  resource  for  constructing  the  C2ISR  Plan  as 
delineated  in  the  AC2ISRC  charter. 

Recommendation.  A  senior  level  (three  star)  staff  position  be  created  from  the  existing  AF/SC 
position  to  oversee  the  important  mission  of  modernizing  and  sustaining  the  Air  Force  C2 
System.  Appropriate  resources  from  the  Air  Staff  should  be  reassigned.  The  AC2ISRC  would 
be  an  important  part  of  the  incumbent’s  operation  and  the  AC2ISRC  should  be  assigned  as  a 
direct  reporting  unit  (some  elements  of  the  AC2ISRC  might  best  remain  in  Air  Combat 
Command  [ACC]). 

6.7  Programming  and  Budgeting 

AC2ISRC  is  charged  with  overseeing  the  entirety  of  the  Air  Force  C  ISR  systems.  This  function 
currently  encompasses  a  budget  of  approximately  $9  billion  per  year  and  117  separate  PEs. 

Many  of  the  PEs  were  created  under  a  different,  non-integrated  management  concept  and  require 
realignment  so  that  they  fit  into  a  logical  management  structure.  This  process  has  started  with  the 
creation  of  a  PE  for  the  Tactical  Air  Force’s  AOC,  but  needs  to  be  extended  to  the  remaining  PE 
structure. 
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When  AC2ISRC  was  established,  a  number  of  PEs  were  assigned  to  its  stewardship.  Some  of 
these  were  clearly  part  of  the  AC2ISRC  overall  mission  and  were  therefore  “core”.  Others  were 
not  directly  part  of  AC2ISRC  but  they  had  an  interest.  These  were  “non-core”  and  were  under 
the  Center’s  cognizance  but  were  not  owned.  In  total  the  PEs  were  about  130  in  number.  Since 
that  time  the  number  has  decreased  to  117.  The  size  of  individual  PEs  varies  widely  from 
$500  million  per  year  to  $  100,000  per  year.  Given  that  each  PE  drives  an  overhead  structure,  if 
only  in  considering  funding  levels,  support  at  AC2ISRC  and  in  the  Pentagon,  and  justification  to 
the  Office  of  Management  and  Budget  and  the  Congress,  some  savings  in  effort  if  not  in  people 
can  be  made  by  consolidation.  In  addition,  consolidation  in  some  logical  sequence  will  provide 
the  much-needed  flexibility  to  quickly  react  with  funding  to  solve  issues  or  leverage  new 
technology  without  reprogramming.  The  structure  of  the  consolidation  needs  careful  attention, 
as  each  of  the  PEs  carries  a  constituency  in  terms  of  military,  industrial,  and  congressional 
proponents. 

Two  methods  of  logically  cataloging  the  C  PEs  were  considered:  by  node  (as  in  AOC,  Control 
and  Reporting  Center,  Airborne  Warning  and  Control  System  [AWACS],  etc.)  or  by  capability 
(as  in  ground  target  attack,  air  target  attack,  etc.). 

Some  pros  and  cons  for  each  follow: 


NODES 


Pros 


Cons 


Recognizable,  physical  entity 
Known  capability  and  perceived 
deficiencies 

Easy  to  understand  at  all  levels 
Flexible  reprogramming 
Overarching  integration  possible 


Exists,  therefore  good  enough 
Already  formed  opinion  as  to  limitations 

Easy  target  for  detractors 
Integration  neglected 


CAPABILITY 


Pros 

System  of  systems  approach 
Difficult  to  envision,  many  possible 
solutions  to  the  same  question 
What  we’re  really  trying  to  achieve 
Flexible  reprogramming 


Cons 

One  system  may  fit  in  many  capabilities 
Diffusion  of  funding  across  many  PEs  for 
single  physical  entity 
May  not  be  clear  how  much  is  enough 


2 

In  order  to  properly  integrate  the  C"  system,  each  program  element  in  the  structure  must  contain 
funding  and  direction  to  provide  the  tools  and  system  management  to  assure  that  the  program 
element  merges  within  the  existing  and  future  operational  and  system  architecture. 


Recommendations 


•  Reorganize  the  PE  structure  in  a  node  construct. 
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•  Relate  PEs  that  provide  operational  capabilities  through  capstone  program  management  directives 
(PMDs),  or  some  similar  structure,  to  assure  that  focus  remains  on  fielding  capabilities,  and  not 
just  systems. 

6.8  Requirements  and  their  Control 
6.8.1  Requirements  Process 

The  formal  Air  Force  requirements  process  in  use  for  all  systems  is  a  formal,  sequential  process 
which  emphasizes  broad-based  corporate  buy-in  regarding  broad  operational  capabilities  and 
recommended  solutions  to  mission  deficiencies.  This  process  is  lengthy,  sequential  and  can  take 
from  well  over  a  year  to  several  years  before  a  final  document  is  prepared  which  initiates 
acquisition  activity.  While  this  process  is  appropriate  for  large,  well-defined  systems  such  as 
aircraft,  it  is  not  responsive  to  the  rapidly  changing  environment  of  information  technology  (IT) 
acquisition,  where  several  generations  of  change  may  be  experienced  in  the  time  taken  to 
articulate  a  single  generation  of  requirements. 

The  concepts  of  evolutionary  acquisition  and  spiral  development  (EA/SD)  have  evolved  to 
enable  the  acquisition  system  to  cope  with  the  accelerated  pace  of  IT  development.  Similarly, 
this  accelerated  pace  demands  a  revised  requirements  process  that  avoids  lock-step  sequential 
articulations  of  required  operational  capabilities  and  recommended  solutions. 

A  requirements  process  responsive  to  EA/SD  has  fundamental  characteristics: 

•  Iterative  through  the  system  lifecycle 

•  Intended  to  be  used  within  EA  blocks 

•  Focused  on  rapid  delivery 

•  Performance  traded  for  cost  and  schedule  control 

•  COTS  solutions  used  where  feasible 

•  Flexible  to  requirements  reflected  in  business  and  technical  strategies 

•  Continuous  user  and  tester  involvement 

•  Flexible  architecture 

•  Conducive  to  experimentation  throughout  the  spiral  process 

•  Based  on  new  decision  points  such  as  stop,  continue,  change,  field,  and  support 

This  process  can  only  work  if  there  is  an  overarching  set  of  priorities  based  on  operational 
concepts  and  operational  architectures  enabling  coherent  action  by  a  diverse  group  of 
participants.  These  operational  architectures  or  operational  concepts  have  not  been  available  to 
the  acquisition  community  in  the  past.  In  fact,  the  TBMCS  program  did  not  even  have  a  draft 
operational  concept  until  ACC/CC  created  a  Tiger  Team  to  develop  such  a  document  in  the 
Spring  of  2000 — over  four  years  after  the  (then)  $180  million  effort  was  put  on  contract,  and  a 
year  after  the  first  operational  tests.  The  using  and  acquisition  communities  apparently  felt  that 
a  union  of  the  three  legacy  systems’  CONOPs  was  sufficient  for  a  description  of  what  should  be 
expected  from  the  integrated  capabilities.  (One  has  to  ask  why  bother  integrating  the  capabilities 
if  that  was  the  case?)  There  is  still  no  operational  architecture  for  the  TBMCS,  and  to  its  credit, 
the  acquisition  community  has  taken  on  the  task  of  developing  such  a  document  in  the  absence  of 
activity  in  the  user  sector.  One  would  suppose  that  it  would  normally  be  the  job  of  the  AC2ISRC 
to  get  such  a  job  done. 
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It  is  clear  that  some  level  of  description  of  the  operational  architecture  desired  is  required  before 
development  or  integration  of  capabilities  into  a  C2  system  should  be  accomplished.  But  DISA 
and  the  Joint  Staff  J3  do  not  seem  to  think  that  necessary  for  GCCS,  as  it  seems  they  do  not  have 
such  a  roadmap.  It  remains  to  be  seen  how  effective  that  “seat  of  the  pants”  approach  to 
evolution  will  be.  They  appear  to  detennine,  on  an  annual  basis,  what  already  developed 
(DII  COE  compliant)  capabilities  should  be  integrated  into  the  GCCS.  Approval  of  these  annual 
capability  increments  then  constitutes  the  Milestone  Review  by  the  Milestone  Decision 
Authority  (MDA)  (see  DoDD  5000. 1).  Such  an  annual  process  of  requirements  determination  is 
much  preferable  to  the  ponderous  process  we  have  used  on  such  as  TBMCS — where  we  have 
tried  to  detennine  all  the  required  operational  perfonnance  at  the  outset,  and  then  embarked  on  a 
development  program  to  build  a  system  to  implement  those  requirements — while  the  user 
community  is  meanwhile  modifying  its  ways  of  operating,  and  developing  its  own  hardware  and 
software  to  accommodate  those  operations.  The  resulting  turmoil  of  requirements  changes 
causes  havoc  in  classical  development  programs  such  as  TBMCS  was.  Frequent  integration  of 
relatively  small  capability  improvements  ,  under  the  aegis  of  an  evolving  operational 
architecture,  appears  a  much  better  approach. 

Recommendations 

•  To  realize  the  Air  Force  vision  of  integrated  C2,  needs  must  be  driven  by  the  C2  concept  of 
operations  mapped  into  desired  operational  capabilities 

•  Desired  capabilities  (referred  to  as  “desirements”)  need  to  be  developed  through  direct 
interactions  between  “operators”  and  “acquirers” 

-  The  desirements  must  define  the  capabilities  but  cannot  define  how  the  capability  is  obtained 

•  The  5000  series  of  DoD  Directives  need  to  be  revised  to  reflect  the  priorities  and  principles 
described  above.  In  essence,  we  recommend  mining  the  ACTDs,  Lab  efforts,  JEFX,  Industrial 
Developments,  etc.,  for  applications  which  have  already  been  developed  and  shown  to  be 
operationally  useful — prioritize  them — and  integrate  them  into  the  C2  system  under  a  level  of 
effort  funding  concept. 

•  Do  not  use  the  classical,  sequential  approach:  collect  system  requirements,  develop, 
operationally  test — this  will  guarantee  the  fielding  of  an  obsolete  system 

6.8.2  Combat  Support  Information 

Recent  contingency  operations  such  as  Desert  Storm,  Bosnia,  and  Kosovo  have  proven  the 
necessity  to  provide  the  Theater  Commander  with  timely,  accurate  and  trusted  infonnation.  The 
Expeditionary  Aerospace  Force  (EAF)  concept  relies  on  integrated  systems  to  provide  an 
enterprise  view  of  combat  support  information.  The  core  competency  to  support  the  EAF  is 
Agile  Combat  Support  (ACS).  The  program  to  implement  the  ACS  concept  is  the  Global 
Combat  Support  System-Air  Force  (GCSS-AF).  GCSS-AF  is  also  needed  for  its  contribution  to 
rapid  mobility  and  information  superiority,  two  other  Air  Force  core  competencies. 

The  current  process  for  providing  combat  support  information  is  too  complex,  fragmented  and 
slow  to  effectively  and  efficiently  meet  warfighter  needs.  Current  data  has  to  be  manually 
verified,  wasting  valuable  time,  and  jeopardizing  missions  and  lives.  GCSS-AF  must  provide 
commanders  real-time  visibility  of  relevant  blue  order  of  battle  infonnation  for  in-garrison  and 
deployed  forces  for  operational  missions  at  any  location  on  the  globe.  The  information  assists 
the  commander  to  control  resources,  plan,  train,  equip,  deploy,  employ,  sustain,  and  reconstitute 
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forces  across  the  full  spectrum  of  military  operations.  The  data  included  in  the  system  vital  to 
the  success  of  the  mission  are  shown  in  Figure  6-3. 

During  Kosovo,  our  current  systems,  primarily  functional  stovepipes,  did  not  provide  a  way  to 
access,  integrate,  or  present  this  information.  The  support  world  turned  to  brute  force  (phone 
calls,  e-mails,  and  faxes)  in  an  attempt  to  assemble  and  verify  this  critical  information.  Our 
leadership  lost  confidence  in  the  information  provided.  Weapons  employment  decisions  were 
impacted. 

In  the  summer  of  1999,  the  Air  Force  CIO  established  a  Tiger  Team  to  pull  together  the 
requirements  and  strategy  for  achieving  a  strong  and  successful  GCSS-AF.  The  report  of  the 
GCSS-AF  Requirements  Integration  Tiger  Team  was  published  on  31  August  1999,  and  is 
included  as  Appendix  6H  of  this  volume.  The  acquisition  panel  strongly  supports  the  Tiger 
Team’s  recommendations. 
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Figure  6-3.  GCSS-AF  Information  Cube 


6.9  Development  and  Integration  Standards 

In  order  to  meet  the  Air  Force  evolutionary  acquisition  objectives  of  deploying  new  or  upgraded 
integrated,  and  interoperable  C2  capability  in  a  rapid  acquisition  timeframe  (18  months  or  less); 
making  use  of  the  latest  commercial  IT,  there  are  several  processes  and  conditions  that  need  to 
be  employed.  We  believe  these  consist  of: 
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•  Well  defined  PEs  encompassing  desired  warfighting  functionality 

•  Stability  in  PE  funding  for  development,  fielding,  and  sustainment  as  a  function  of  well  defined 
priorities 

•  Disciplined  requirements  generation  and  control  process  (CONOPS,  operational  architecture, 
etc.)  involving  all  stakeholders 

•  Defined  technical  architecture  (information  technology  standards) 

•  Educated  and  disciplined  use  of  the  spiral  development  process 

•  Well  defined  objective  system  architecture  and  migration  path 

•  Integration  of  test  and  evaluation  (T&E)  throughout  C2  development  lifecycle 

Many  development  programs  fail  or  have  limited  success  because  one  or  more  of  these 
conditions  are  absent.  Each  is  necessary  in  some  form  for  successful  evolutionary  acquisition 
objectives.  This  section  will  focus  on  the  items  5  and  6,  as  the  other  items  are  covered  in 
subsequent  sections  of  this  report.  For  the  purposes  of  this  section,  “development”  is  defined  to 
include  life  cycle  evolution  of  software-intensive  systems  and/or  such  related  practices  as  legacy 
system  replacement  and  integration  of  COTS  or  government-off-the-shelf  components  into  an 
existing  baseline  system. 

6.9.1  Evolutionary  Acquisition  and  Spiral  Development 

The  concepts  of  the  EA/SD  process  have  been  studied,  experimented,  and  implemented  in 
academia,  government,  and  industry  to  various  degrees.  The  spiral  development  is  a  process 
initially  described  by  Dr.  Barry  Boehm  in  the  late  1980s.  In  the  1990s  it  became  more  widely 
adopted  throughout  the  software  engineering  community  in  various  forms.  Its  basic  notion  of 
iteration  has  been  generally  accepted  as  preferable  to  a  rigorous  sequence  of  events  (“waterfall”) 
or  large-scale  rollout  (“big  bang”)  of  a  system.  As  defined  by  Boehm,  spiral  development  is  “a 
risk-driven  process  model  generator. .  .used  to  guide  multi-stakeholder  concurrent  engineering  of 
software-intensive  systems.”  It  is  characterized  by  “a  cyclic  approach  for  incrementally  growing 
a  system’s  definition  and  implementation  while  decreasing  its  degree  of  risk.”  It  must  include  “a 
set  of  anchor  point  milestones  for  ensuring  stakeholder  commitment  to  feasible  and  mutually 
satisfactory  system  solutions.”  Commercial  IT  companies  practice  EA/SD  in  some  form  as 
evidenced  by  the  well  know  practices  of  alpha  and  beta  release  of  products  and  regular  fonnal 
version  release  of  COTS  products  with  increasing  capability.  However  each  company  has 
probably  developed  its  own  unique  versions  of  the  process  and  the  details  are  not  that  visible  to 
the  DoD  community.  Thus,  the  model  and  processes  of  detennining  objectives,  alternatives,  risk 
analysis,  artifact  development,  stakeholder  involvement,  and  decision-making  are  not  visible. 
Although  opinions  vary  on  the  acquisition  system  attributes  where  EA/SD  works  well,  most  feel 
there  are  significant  benefits  to  be  gained  in  its  use  in  the  Air  Force  C2  domain.  The  Air  Force 
leadership  is  convinced  to  the  point  that  EA/SD  is  now  directed  for  use  on  all  C  acquisitions 
unless  the  user  and  MDA  agree  not  to  use  it  (Air  Force  Instruction  [AFI]  63-123). 


35  Dr.  Barry  Boehm,  “A  Spiral  Model  of  Software  Development  and  Enhancement,”  Computer,  May  1988, 
pp.  61-72. 
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State  of  C2  Evolutionary  Acquisition  and  Spiral  Development  in  the  Air  Force.  The  Air 

Force  has  made  an  initial  start  at  beginning  a  fonnal  transition  to  EA/SD  for  acquisition  of  C2 
systems.  Research,  results,  and  guideline  documents  have  been  produced: 

•  Reducing  Air  Force  Acquisition  Response  Times:  Developing  a  Fast  and  Responsive 
Development  System,  1  March  2000  (SAF/AQ) 

•  Air  Force  Evolutionary  Acquisition  Guide  Draft,  March  2000  (SAF/AQ) 

•  AFI  63-123  Evolutionary  Acquisition  for  C2  Systems,  1  April  2000  (SAF/AQII) 

•  Spiral  Development  Handbook  Release  0.1,  1  June  1999  (ESC) 

Some  of  the  shortfalls  in  these  documents  are  the  lack  of  discussion  of  the  spiral  development 
“invariants,  variants,  and  anchor  point  milestones”  as  defined  by  Dr.  Boehm.  Another  shortfall 
is  the  lack  of  discussion  of  the  importance  of  an  “architecture  first”  approach.  This  doesn’t  mean 
that  the  operational,  technical,  and  system  architectures  need  to  be  totally  defined  first,  but 
enough  of  it  has  to  be  developed  up  front  to  ensure  that  the  first  increment  is  sufficiently  robust 
to  allow  subsequent  scaling  for  additional  later  increments.  Other  subjects  that  are  missing 
include  explicit  process  guidance  and  tools  for  converging  on  next  level  objectives,  constraints, 
and  alternatives.  These  documents  will  need  to  be  supplemented  and  revised  based  on 
implementation  of  recommendations  in  this  report  and  other  research  results. 

There  are  several  on-going  Air  Force  C  development  projects  that  are  explicitly  using  SD.  The 
Global  Theater  Weather  Analysis  and  Prediction  System  has  completed  several  successful  spirals 
and  four  incremental  deliveries  that  are  operational.  This  project  is  both  developed  by  the 
contractor  and  deployed  operationally  at  the  user  facility  (AFWA)  and  this  perhaps  enhanced 
integrated  product  team  (IPT)  effectiveness  toward  user  objectives.  At  one  point  a  mini  spiral 
was  done  in  6  weeks  which  resulted  in  an  integrated  capability  to  operationally  track  and  predict 
hurricane  paths.  The  Operational  Weather  Squadron  Production  System  has  also  completed 
several  spirals  and  is  being  deployed  at  the  weather  squadrons.  The  Attack  Options  Decision 
Aid  is  using  SD  and  has  successfully  taken  part  in  two  JEFX  experiments  as  a  component  in  the 
time-critical  target  process.  Although  successful,  the  team  has  had  some  struggle  with 
requirements  management  (growth)  and  development  test  and  evaluation  (DT&E)  definition 
tradeoffs  as  a  result  of  the  team  learning  the  spiral  development  process  along  the  way.  The 
JEFX  experiments  use  the  spiral  process  for  integrating  the  experiment  C2  configuration 
infrastructure  and  initiatives,  however  very  little  capability  has  been  transitioned  to  operational 
use  at  this  point.  The  Space  Weather  Analysis  and  Forecast  System  is  also  underway  as  a  spiral 
development  and  is  about  to  begin  DT&E  of  the  first  thread.  This  program  has  had  to  resolve  an 
issue  of  the  SPO  wanting  design  documentation  much  like  a  waterfall  development  instead  of 
waiting  for  as  built  design  documentation.  The  Integrated  Broadcast  System  was  also  started 
under  EA/SD  but  was  tenninated  just  prior  to  completion  and  deployment  of  the  first  increment. 
The  failure  was  in  large  part  due  to  the  lack  of  or  ineffectiveness  of  the  stakeholder  IPT  members 
in  controlling  requirements  growth  and  identifying,  analyzing,  and  focusing  spiral  efforts  on  the 
risks. 

Perhaps  the  largest  and  most  successful  Air  Force  development  program  using  spiral 
development  (referred  to  as  the  Ada  Process  Model  before  the  tenn  “spiral  development”  was 
popular)  was  Command  Center  Processing  and  Display  System-Replacement  (CCPDS-R)  for 
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Cheyenne  Mountain  Upgrade.  The  CCPDS-R  project  is  discussed  and  well  documented  .  Its 
Ada  Process  Model  was  the  predecessor  of  the  Rational  Unified  Process  and  University  of 
Southern  California  (USC)  MBASE  approach,  which  have  been  used  on  a  number  of  successful 
spiral  projects  .  In  addition,  the  CCPDS-R  project  used  a  number  of  working  groups  (display 
and  user  interface,  algorithm,  interface  control,  security,  and  test)  throughout  the  life  of  the 
program  with  membership  from  all  stakeholders.  Decisions  from  the  working  groups  were 
factored  into  subsequent  design  and  software  builds  based  on  user  inputs  and  risk  assessment. 
The  spiral  process,  including  an  “architecture  first”  approach,  resulted  in  successful  incremental 
delivery  of  three  subsystems  (missile  warning,  forward  user  processing  and  display,  and 
USSTRATCOM  unique)  on  a  fixed  price  incentive  contract.  Incremental  delivery  of  operational 
capability  within  a  subsystem  was  not  acceptable  because  of  the  nature  of  the  operational 
ITW/AA  mission,  which  could  not  be  performed  with  a  partial  capability. 

There  are  a  few  other  projects  that  have  had  SD  characteristics  even  though  they  didn’t  start  out 
explicitly  with  the  SD  objective.  These  are  Eagle  Vision  and  Air  Force  Operations  Resource 
Management  System.  Both  have  produced  incremental  capabilities  using  a  spiral  like  process. 

The  Air  Force  also  has  some  success  employing  evolutionary  acquisition/spiral  development 
methodologies  in  other  communities.  AF/XOI  manages  several  DODIIS  intelligence  mission 
applications  and  acts  as  the  executive  agent  for  test  and  integration  for  approximately  35  systems 
developed  under  the  General  Defense  Intelligence  Program.  The  DODIIS  development, 
integration,  and  test  model  implements  the  DoDD  5000  and  4630  Acquisition  and 
Interoperability  Directive,  and  is  consistent  with  the  Clinger-Cohen  Act  of  1996.  Detailed 
DODIIS  standards  and  instructions  provide  managers,  developers  and  users  with  guidance 
relative  to  programming  and  budgeting,  DII  compliance,  configuration  management,  test  and 
evaluation,  training,  IT  security,  and  software  deployment.  This  process  has  been  largely 
adopted  by  DISA  for  GCCS  integration  and  testing.  DODIIS  compliance  testing  occurs  in  the 
Air  Force-managed  JITF.  Spiral  development  programs  successfully  developed,  fielded,  and 
maintained  by  the  Air  Force  for  DODIIS  include  the  CSP,  the  ISSE  Guard  and  most  recently, 
PROJECT  BROADSWORD. 

At  this  point  in  time,  the  overall  Air  Force  EA/SD  experience  and  results  are  limited  and  mixed. 
It  is  likely  that  a  major  reason  for  mixed  results  is  that  training  and  experience  at  the  project  IPT 
level  has  been  very  limited  and  thus  the  individual  teams  are  feeling  their  way  along. 

The  2000  USC/Software  Engineering  Institute  Symposium  on  Spiral  Development.  A 

number  of  organizations  are  successfully  applying  the  spiral  development  model  (SDM)  and 
finding  it  valuable  in  addressing  such  challenges  as  rapid  development,  COTS  software 
integration,  new  technologies,  and  product-line  management.  Other  organizations  have 
experienced  difficulties  with  spiral  development  due  to  over-relaxed  controls,  underestimated 
risks,  existing  sequential  development  policies,  inflexible  financing  mechanisms,  ingrained 
cultures,  and  confusion  about  what  spiral  development  is  and  how  to  apply  it.  To  attack  these 
problems,  a  workshop  was  held  February  9-11,  2000  at  the  University  of  Southern  California 
under  the  sponsorship  of  its  Center  for  Software  Engineering  (CSE)  and  the  Software 
Engineering  Institute  (SEI)  of  Carnegie  Mellon  University. 


36W.E.  Royc e,  Software  Project  Management:  A  Unified  Framework,  Addison  Wesley,  1998. 

37  Boehm  et  at,  “Using  the  Win-Win  Spiral  Model:  A  Case  Study,”  IEEE  Computer,  July  1998,  pp. 33-44. 
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The  Workshop  objectives: 

•  Clarify  the  nature  of  spiral  development 

•  Create  a  common  understanding  of  the  current  state  of  the  practice  (“as-is”) 

•  Share  experiences  in  applying  it  in  various  situations 

•  Identify  its  critical  success  factors 

•  Create  a  vision  of  best  practice  (“to  be”) 

•  Identify  and  address  institutional  barriers/inhibitors  to  successful  spiral  usage  such  as  policy, 
financial,  or  cultural  constraints 

The  results  of  the  workshop  are  documented  in  “The  2000  USC-SEI  Workshop  on  Spiral 
Development”  March  2000,  report  number  CMU/SEI  00-SR-06.  The  report  can  be  accessed  on 
the  web  at  http://www.sei.cmu.edu/activities/cbs/spiral2000.  The  workshop  participants  and 
briefings  were  from  academia,  government,  and  commercial  and  DoD  contractors.  None  of  the 
workshop  participants  represented  DoD  organizations  that  actually  used  software  developed  with 
the  spiral  approach.  This  suggests  that  the  user  community  has  had  little  experience  with 
products  delivered  under  EA/SD,  or  is  not  yet  aware  of  the  large  opportunity  it  affords  them  to 
influence  near  term  delivered  capabilities.  A  brief  summary  of  key  issues  and  recommendations 
from  the  workshop  follows. 

Dr.  Boehm  opened  the  workshop  with  a  presentation  on  the  following  key  concepts  referred  to  as 
invariants: 

•  Concurrent  determination  of  all  key  artifacts.  Concurrent  determination  of  all  key  artifacts 
means  that  the  concept  of  operations,  requirements,  design,  and  code  are  all  progressively  defined 
as  the  system  evolves  through  the  spirals.  This  is  essential  to  avoid  premature  commitment  to 
system  requirements,  design,  use  of  COTS,  and  cost/schedule/performance.  The  relative  amount 
of  each  artifact  developed  in  a  specific  spiral  increment  varies  based  on  risk. 

•  Recurring  stakeholder  review.  Recurring  stakeholder  review  of  objectives,  constraints, 
alternative,  and  risks  between  spiral  increments  is  an  essential  element.  This  avoids  wasting  effort 
in  elaborating  alternatives  that  will  be  unsatisfactory  to  the  user. 

•  Level  of  activity  in  each  cycle  driven  by  risk.  Level  of  activity  in  each  cycle  in  each  area  is 
driven  by  risk.  This  is  one  of  the  most  key  differences  between  spiral  development  and 
incremental  development.  By  focusing  on  risk  areas  and  then  targeting  those  areas  for  further 
development  the  overall  level  of  risk  in  the  system  is  driven  lower  and  lower. 

•  Degree  of  detail  in  all  key  artifacts  driven  by  risk.  For  the  same  reason,  the  degree  of  detail  in 
each  key  artifact  is  also  driven  by  risk 

•  Management  of  stakeholder  commitments  via  anchor  points.  Using  anchor  points  to 
management  of  stakeholder  commitments  is  to  avoid  analysis  paralysis,  unrealistic  expectations, 
requirements  creep,  architectural  drift,  unsustainable  architectures,  and  traumatic  cutovers. 

•  Emphasis  on  system  activities  and  artifacts  versus  software  artifacts.  An  emphasis  on  system 
activities  and  artifacts  versus  software  artifacts  is  to  avoid  premature  suboptimization  of 
hardware,  software  and  development  considerations.  The  relative  amount  of  hardware  versus 
software  development,  of  overall  capability,  and  of  degree  of  productization  in  each  spiral 
increment  should  vary,  as  always,  based  on  risk. 

The  full  briefing  can  be  accessed  on  the  web  at  http://www.sei.cmu.edu/activities/cbs/spiral2000. 
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The  first  day  and  a  half  of  the  workshop  were  devoted  to  presentations  by  executives  and 
practitioners  representing  government,  commercial  users,  solution  providers,  and  contractors.  In 
retrospect,  these  presentations  evoked  these  themes  and  comparisons: 

•  The  term  spiral  development  is  not  well  defined  or  understood.  For  some  it  means  any 
development  approach  with  recurrent  planning  activities,  while  others  add  constraints  such  as 
“risk-based”  and  “anchor  points.” 

•  Spiral  development  can  be  sharply  defined  with  invariants  and  variants;  that  is,  those  aspects  that 
are  essential  in  every  spiral  project  and  those  other  aspects  which  can  differ  between  projects. 

•  Spiral  development  and  evolutionary’  acquisition  are  different,  but  related.  An  evolutionary 
process  qualifies  technology  before  embarking  on  spiral  development. 

•  Spiral  development  differs  between  government  organizations  and  commercial  organizations. 

•  Some  spiral  time  cycles  are  still  fairly  long — two  or  three  years — while  others  are  much  shorter — 
two  to  three  months.  Typically,  longer  cycles  are  found  in  government. 

•  Some  of  the  critical  success  factors  for  spiral  development: 

-  Risk  must  be  managed 

-  The  culture  must  be  trusting 

-  Stakeholders  must  be  involved 

-  The  technology  must  be  ready 

-  Requirements  must  be  flexible 

The  second  half  of  the  workshop  was  devoted  to  small  work  group  sessions,  each  addressing  a 
different  topic.  These  groups  were  particularly  charged  with  recommending  concrete  actions  for 
progress.  They  made  forty-nine  recommendations  which  fall  into  seven  categories: 

•  Define  SDM:  Refine  and  promulgate  the  definition  of  the  spiral  development  model. 

•  Promote  SDM:  Spread  awareness  of  the  spiral  model  among  developers,  managers,  and 
executives. 

•  Educate  about  SDM:  Provide  appropriate  courses  through  universities  and  professional  training 
organizations. 

•  Adapt  to  SDM:  Revise  policies,  processes,  and  practices  to  encourage  spiral  development  where 
appropriate.  These  recommendations  were  addressed  primarily  to  DoD,  but  will  reward  use  as  a 
checklist  for  any  large  organization. 

•  Improve  SDM:  Explore  the  spiral  development  model  and  human  behavior  to  determine  what 
improvements  are  possible  and  how  they  should  be  formulated. 

•  Enhance  teamwork:  Improve  teaming  techniques,  especially  as  they  apply  to  spiral  development. 

•  Study  SDM:  Conduct  research  to  validate  the  spiral  development  model,  evaluate  its  potential  for 
return  on  investment,  and  determine  the  mutual  impacts  between  it  and  people. 

For  each  recommendation,  the  workgroup  proposed  an  action  agent,  the  person  or  group  most 
likely  to  be  able  to  take  the  necessary  actions.  In  general,  the  Define  SDM,  Improve  SDM,  and 
Study  SDM  actions  are  expected  to  be  done  by  universities  and  research  centers,  especially 
Center  for  Software  Engineering  and  SEI;  all  parties  must  act  on  Educate  about  SDM  and 
Promote  SDM;  and  OSD  should  Adapt  to  SDM  with  respect  to  DoD  policies,  processes,  and 
practices. 
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Findings 

•  The  practice  of  EA/SD  in  the  Air  Force  (  and  DoD)  is  ad  hoc  and  not  well  defined 

•  There  is  no  Air  Force  funding  for  implementing  EA/SD  as  a  core  competency 

•  The  existing  AFI  63-123  on  EA/SD  does  not  provide  adequate  guidance  to  stakeholders.  There  is 
no  description  of  the  spiral  development  invariants,  variants,  and  anchor  point  milestones.  There 
is  no  explicit  description  of  process  guidance  and  tools  available  for  guiding  spiral  processes  and 
converging  on  next  level  objectives,  constraints,  and  alternatives. 

•  There  is  no  Air  Force  training  program  for  stakeholders  in  the  effective  practice  of  EA/SD 

•  Academia  is  very  interested  in  working  with  the  Air  Force,  DoD,  and  industry  in  advancing  the 
state  of  EA/SD. 

Recommendations 

•  Continue  to  invest  in  EA/SD  as  a  core  competency 

•  Partner  with  USC  and  SEI  in  continued  EA/SD  development.  Enlist  USC,  SEI,  and  commercial 
industry  support  in  the  review,  improvement,  and  refinement  of  AFI  63-123  and  SD  handbooks. 

•  The  Air  Force  (and  DoD)  needs  to  treat  EA/SD  as  a  key  engineering/management  capability  for 
(software  intensive)  C2  systems.  Task  SEI  to  develop  a  Capability  Maturity  Model  (CMM)  for 
EA/SD.  The  CMM  would  apply  to  all  the  EA/SD  stakeholders,  not  just  industry. 

•  Task  SEI  and  ESC  to  develop  a  training  course  in  the  implementation  of  EA/SD 

•  Provide  EA/SD  team-building  sessions  for  all  new  projects/program  managers  to  get  projects 
started  on  an  efficient  and  effective  collaborative  pathway 

6.9.2  System  Architecture 

Although  system  architecture  development  is  just  one  of  the  key  activities  of  spiral  development, 
it  is  important  enough  to  highlight  in  this  section.  The  C4ISR  Architecture  Framework  2.0 
defines  the  system  architecture  view  as  a  description,  including  graphics,  of  systems  and 
interconnections  providing  for  warfighting  functions.  For  a  domain,  the  systems  architecture 
view  shows  how  multiple  systems  link  and  interoperate,  and  may  describe  the  internal 
construction  and  operations  of  particular  systems  within  the  architecture.  For  the  individual 
system,  the  system  architecture  view  includes  the  physical  connection,  location,  and 
identification  of  key  nodes  (including  materiel-item  nodes),  circuits,  networks,  warfighting 
platforms,  etc.,  and  it  specifies  system  and  component  performance  parameters  (for  example, 
mean  time  between  failure,  maintainability,  availability).  The  system  architecture  view 
associates  physical  resources  and  their  performance  attributes  to  the  operational  view  and  its 
requirements  following  standards  defined  in  the  technical  architecture. 

As  important  as  the  operational  and  technical  architectures  are,  it  is  often  the  system  architecture 
that  creates  problems  with  C  acquisitions.  A  major  part  of  the  system  architecture  is  that  of 
automated  information  system(s)  and  the  corresponding  software  architecture.  These  areas  of 
the  system  architecture  are  often  understood  by  a  small  group  of  computer  science  experts  and 
are  not  well  integrated  with  the  rest  of  the  system  acquisition.  It  is  also  these  areas  of  system 
architecture  that  have  the  most  impact  on  the  resulting  “-ilities”  of  the  system.  This  is  where  the 
system  attributes  of  flexibility,  scalability,  reliability,  availability,  and  security  are  built  in  and 
thus,  have  high  leverage  for  system  success  or  failure. 
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The  spiral  development  process  addresses  these  risks  via  the  anchor  point  milestones  of  Life 
Cycle  Objectives,  Life  Cycle  Architecture  (LCA),  and  other  project  unique  milestones.  The 
process  evolves  the  system  architecture,  through  architectural  specifications,  prototypes,  COTS 
elements,  and  system  architecture  instantiations  in  order  to  evaluate  the  architecture  attributes 
and  manage  the  risks.  For  evolving  theater  C2  systems,  this  may  mean  a  periodic  spiral  of 
updating  the  objective  system  architecture  and  the  migration  plan  from  the  current  architecture  to 
the  new  objective  architecture. 

6.9.3  Demonstration  Based  Development 

The  term  “demonstration-based  development”  refers  to  a  set  of  spirals  and  decision  points  within 
an  EA  increment  but  after  the  LCA  anchor  milestone  used  to  periodically  evaluate  and  validate 
elements  of  the  operational,  technical  and  system  architectures  and  user  interface  attributes. 

Each  demonstration  needs  to  be  conducted  to  exercise  an  intermediate  software  build  with 
planned  threads  and  scenarios  to  evaluate  a  subset  of  evolving  system  functions,  performance, 
the  “-ilities”,  and  user  interface.  Continuous  user  involvement  throughout  the  software  life  cycle 
is  critical  to  user  acceptance  of  the  next  fielded  version.  This  typically  includes  user 
participation  in  IPTs  during  the  functional  requirements  analysis,  design  (particularly  for  Human 
Systems  Interface),  training  development,  and  test  planning  activities.  Even  more  valuable  is  the 
user  feedback  from  participation  in  the  evolving  increment  demonstrations.  Additional  valuable 
benefits  from  the  demonstration  spirals  are  the  forced  attention  to  achieving  a  robust  product  and 
creating  the  basis  for  test  agreements  before  DT&E  and  operational  test  and  evaluation  (OT&E). 

6.10  A  Process  to  Allow  Rapid  Integration 
6.10.1  Introduction 

One  of  the  major  differences  between  command  and  control  systems  evolution  and  that  of 
weapons  systems  using  more  established  technologies  is  the  pace  of  technological  change.  New 
generations  of  digital  hardware,  software,  and  telecommunications  technologies  are  frequently 
available  in  months  as  opposed  to  decades.  This  rapid  evolution  requires  a  command  and  control 
system  evolution  process  that  accommodates  such  change.  The  process  defined  in  our  current 
basic  acquisition  publications  (for  example,  DoDD  5000.1)  and  requirements  directives  will  not 
suffice.  As  noted  above  the  intelligence  and  DISA  communities  have  established  a  process 
which  at  least  appears  to  do  a  better  job  of  accommodating  rapid  evolution.  They  rely  on  an 
evolving  set  of  standards  for  integration  (the  DII  COE  in  the  case  of  DISA)  that  allow  newly 
developed  capabilities  (which  may  have  taken  years  to  bring  to  fruition)  to  be  integrated  in 
months  into  the  evolving  baseline  C  or  intelligence  analysis  systems.  The  classical  development 
approach  documented  in  such  as  5000.1  assumes  that  such  developments  are  treated  as 
prototypes — and  another  whole  development  cycle  (consuming  again  years)  is  used  to  integrate 
the  new  capability  into  the  baseline  system.  While  the  DII  COE  standard  may  not  be  the  best 
one,  such  a  process  appears  to  be  the  best  available  for  integration  of  new  capabilities  into 
systems  such  as  TBMCS. 

It  is  the  Air  Force’s  desire  to  evolve  toward  web-enabled  systems,  and  minimize  the  necessity  to 
depend  on  cumbersome  client-server  architectures  such  as  was  the  norm  when  TBMCS  was 
started  in  the  early  90s.  This  evolution  is  apparently  what  DISA  is  planning  for  the  DII  COE.  It 
would  seem  worthwhile  for  Air  Force  to  use  DII  COE  as  a  near-tenn  platform  standard  to  allow 
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rapid  integration  of  capabilities  into  evolving  C  systems,  and  to  steer  the  evolution  of  this 
standard  toward  one  supporting  the  JBI.  Support  in  the  Air  Force  for  the  COE  has  been  half¬ 
hearted  at  best,  and  it  has  frequently  been  treated  as  a  needless  and  costly  encumbrance.  We 
need  to  adopt  an  approach  for  the  integration  of  capabilities  into  joint  systems  which  serve  the 
CINCs  which  allows  for  integration  of  appropriate  technology  as  soon  as  it  makes  sense  to 
introduce  it.  The  “big  bang”  development  and  integration  approach  will  not  allow  that  to 
happen. 

6.10.2  Evolutionary  Integration — The  C2  Testbed 

An  essential  element  to  the  development  and  integration  of  new  C  capabilities  is  a  testbed  that 
can  serve  a  combined  and  integrated  team  of  operators,  developers,  integrators,  trainers, 
supporters,  and  testers  to  provide  a  collaborative  environment  for  the  evolution  of  command  and 
control.  We  heard  many  pleas  for  location  at  the  Rome  AFRL/IF  Site  and  at  Flanscom  AFB,  but 
we  see  the  need  to  be  close  to  the  operators.  We  believe  such  a  testbed  should  be  established  at 
Langley  AFB,  under  the  control  of  a  management  board  including  AC2ISRC,  ESC,  AFRL  and 
Air  Force  Operational  Test  and  Evaluation  Center  (AFOTEC)  (plus  Air  Education  and  Training 
Command  training  and  AFMC  logistics  personnel),  with  primary  lead  by  AC2ISRC.  While  the 
main  facility  might  be  at  Langley  AFB,  important  satellite  development,  integration,  and 
simulation  work  can  and  should  take  place  at  other  locations  (Hanscom  AFB,  AFRL/IF, 
operational  AOCs,  etc.) 

Above  all,  the  testbed  should  be  populated  with  a  joint  team,  a  partnership,  operating  in  a 
harmonious  relationship  between  the  activities  concerned  to  the  common  goal  of  transitioning 
command  and  control  development  initiatives  and  operational  concepts  to  the  field.  No  person  is 
in  a  liaison  role:  All  are  IT-operations  professionals  of  high  caliber  with  long-tenn  assignments. 
Figure  6-4  describes  the  key  responsibilities. 

The  testbed  should  be  equipped  with  that  equipment  representative  of  fielded  equipment,  as  well 
as  that  equipment  that  is  necessary  to  perform  the  specific  functions  of  the  assigned 
responsibilities. 


Operator  Responsibilities 

Developer  Responsibilities 

■Maintain  CONOPS  &  Operational  Architecture 

■Respond  to  CONOPS  and  other  user  needs 

■Prioritize  desired  capabilities 

■Assure  technologies  available  for 

■Operationally  evaluate  developed  capabilities 

integration 

■Plan,  program,  and  budget  for  personnel  and 

■Participate  in  ACTDs,  JEFXs,  Battlelab 

su  pport 

activities 

■Foster  development  of  new  capabilities  (ACTDs, 

■Conduct  spiral  developments  as  needed 

AOCs,  etc.) 

Integrator  Responsibilities 

Ops  Tester  Responsibilities 

■Maintain  System  and  Technical  Architectures 

■Participate  in  engineering  process 

■System  configuration  control 

■Do  main  evaluation  during  development 

■Engineering  and  data  assessment,  risk  analysis 

■Certify  performance  post-integration 

■Integration  and  testing 

system 

+  trainers,  sustainers,  etc. 


Figure  6-4.  Testbed  Team  Responsibilities 
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The  testbed  would  provide  the  basis  for  experimentation  with  operational  and  technical  concepts, 
as  well  as  the  final  tests  of  developments  and  the  integration  of  capability  into  the  operational 
systems  in  the  field. 

Figure  6-5  depicts  the  cyclical  process.  Operators  develop  operational  concepts  and 
architectures  and  identify  new  technology  developments  needed.  Developers  develop 
prototypes,  demonstrations,  and  ACTDs  as  well  as  identifying  new  operational  concepts  made 
possible  by  technology  advancements.  Integrators  develop  system  and  technical  architectures 
and  integrate  the  new  capabilities  into  the  testbed,  and  later,  into  the  operational  system.  Testers 
conduct  capability  testing  (on  a  less  formal  basis  than  performance  testing),  and  trainers  develop 
training  concepts.  Much  is  done  in  parallel  at  the  testbed,  but  the  result  is  a  cyclical  refresh  of 
the  operational  capability  in  the  field.  Major  physical  and  functional  components  of  the 
command  and  control  testbed  may  be  physically  separated  from  the  main  facility. 


Prototypes 


CONOPS-based  capability  needs 


CAPABILITY 

NEEDS 


OPERATIONAL 

SITES 

NAFs 

JFACCs 

Wings 

Navy  C2  ships... 


Technology 

Developed 
capabilities  from 
AFRL,  ACTD, 
JEFX,  field,... 


SYSTEM 

UPDATES 


Capability 

tests 


Integration  of 
developed  capabilities 


Figure  6-5.  Evolutionary  Integration 


It  is  the  Air  Force’s  desire  to  evolve  toward  web-enabled  systems,  and  minimize  the  necessity  to 
depend  on  cumbersome  client-server  architectures  such  as  was  the  norm  when  TBMCS  was 
started  in  the  early  90s.  This  evolution  is  apparently  what  DISA  is  planning  for  the  DII  COE.  It 
would  seem  worthwhile  for  Air  Force  to  use  DII  COE  as  a  near-tenn  platform  standard  to  allow 
rapid  integration  of  capabilities  into  evolving  C2  systems,  and  to  steer  the  evolution  of  this 
standard  toward  one  supporting  the  JBI.  Support  in  the  Air  Force  for  the  COE  has  been  half¬ 
hearted  at  best,  and  it  has  frequently  been  treated  as  a  needless  and  costly  encumbrance.  We 
need  to  adopt  an  approach  for  the  integration  of  capabilities  into  joint  systems  which  serve  the 
CINCs  which  allows  for  integration  of  appropriate  technology  as  soon  as  it  makes  sense  to 
introduce  it.  The  “big  bang”  development  and  integration  approach  will  not  allow  that  to 
happen. 
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6.11  Testing 

2 

T&E  of  C  systems  is  an  evolving  Air  Force  area  of  discipline.  Beginning  in  1995,  the  Air  Force 
recognized  that  T&E  of  C  ,  at  the  developmental  test  level  was  seriously  flawed.  A  series  of 
initiatives,  stimulated  by  HQ  AF/TE,  resulted  in  establishment  of  a  formal,  structured,  process- 
oriented  T&E  team  at  ESC.  A  staff  element  (ESC/TE)  is  responsible  for  ensuring  that  each  ESC 
acquisition  program  develops  and  implements  an  adequate  test  program,  incorporating 
appropriate  contractor,  development  and  operational  testing. 

6.11.1  Development  Test  and  Evaluation 

Development  Test  (DT),  which  may  include  contractor  testing,  is  an  integral  part  of  the 
development  process,  and  is  primarily  conducted  in  the  early  phases  of  a  program.  It  is  intended 
to  evaluate  design  approaches,  validate  analytical  models,  quantify  contract  technical 
performance  and  manufacturing  quality,  measure  progress  in  system  engineering  design  and 
development,  minimize  design  risks,  predict  integrated  system  operational  performance,  and 
identify  system  problems  to  allow  for  early  and  timely  resolution  or  correction.  OT&E 
(described  below)  cannot  compensate  for  inadequate  DT,  since  the  DT  phase  is  crucial  to  the 
technical  system  characterization  that  must  precede  OT&E. 

6.11.2  Operational  Test  and  Evaluation 

OT&E,  specifically  initial  OT&E,  is  the  testing  and  evaluation  conducted  on  production  or 
production  representative  articles  to  decide  whether  to  field  a  system  or  to  characterize  that 
system’s  effectiveness  and  suitability.  In  the  case  of  C  OT&E,  this  characterization  may  be  the 
most  important  function,  since  a  spirally  developed  system  seldom  has  a  Milestone  Ill-type 
episodic  decision  point.  It  is  also  important  to  note  that  OT&E  is  concerned  with  the  use  of  the 
system  in  its  intended  environment  and  may  evaluate  system  interfaces  and  perfonnance  even  if 
those  parameters  were  not  included  in  the  original  specifications  and  design. 

6.11.3  Complicating  Factors 

The  classic  DT  and  operational  test  (OT)  structures  described  above  were  developed  in  the  years 
before  the  instantiation  of  the  significant  acquisition  reform  activities  of  the  1990s.  Initiatives 
such  as  COTS,  Cost  as  an  Independent  Variable,  Component  Based  Design  and  TSPR,  while 
meritorious  in  many  respects,  all  exert  downward  pressure  on  program  costs  with  a  concomitant 
pressure  to  reduce  SPO-controlled  DT.  To  the  extent  that  DT  is  not  comprehensive,  OT  must 
attempt  to  fill  the  gap  or  risk  sending  an  incompletely  characterized  system  to  the  user.  In 
essence,  the  system  must  demonstrate  stabilized  performance  in  a  stressing  environment  before 
productive  dedicated  OT  can  begin. 

6.11.4  CONOPS  and  Operational  Architectures 

With  C  systems  in  particular,  the  T&E  concept  is  heavily  dependent  upon  the  intended 
framework  for  employment.  The  operational  tester  cannot  adequately  characterize  a  C2  system 
and  its  perfonnance  unless  the  user  and  developer  have  produced  a  CONOPS  and  operational 
architecture  which  specify  the  system’s  intended  use,  the  projected  interfaces,  and  the  planned 
operational  benefits  of  the  system.  The  CONOPS  and  operational  architecture  should  therefore 
be  required  elements  in  the  SPO’s  certification  of  readiness  for  IOT&E. 
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6.11.5  GCCS  and  T&E 

The  GCCS  was  examined  as  an  exemplar  for  C  acquisition.  While  GCCS  has  numerous 
commendable  program  attributes,  replication  of  that  management  scheme  should  avoid  the 
following  problems.  First,  there  is  no  written  operational  architecture  for  GCCS.  As  noted 
above,  such  an  architecture  is  crucial  to  effective  operational  evaluation  and  characterization  of 
the  deployed  system.  Second,  it  is  not  clear  how  the  developing  agency,  DISA,  conducts  fonnal 
OT&E  of  deployed  systems.  This  means  that  there  is  no  stressing  evaluation  of  either  the 
complete  system  or  its  component  parts  in  advance  of  actual  operations.  Extensive  DT, 
interoperability,  and  security  testing  is  accomplished  but  these  essential  activities  do  not 
compensate  for  the  lack  of  installed,  full-up  system  operational  tests.  Similarly,  DODIIS 
rigorously  tests  at  the  component,  interoperability,  and  security  levels  but  also  includes  AFOTEC 
as  the  OT  agent  on  many  systems  of  Air  Force  interest.  The  DODIIS  process  is  detailed  in 
Appendix  6J  of  this  volume. 

6.11.6  Evolutionary  Acquisition  and  Spiral  Development 

The  Air  Force  has  clearly  specified  most  procedures  for  EA  and  SD  in  AFI  63-123.  Left 
unspecified,  however,  are  requirements  for  operational  architectures  and  CONOPS.  As 
discussed  above,  these  elements  are  crucial  to  characterization  of  the  system’s  effectiveness  and 
suitability.  Also  unspecified  is  the  specific  form  of  OT&E.  Unless  the  Operational  Test  Agency 
(OTA)  is  expected  to  be  continuously  involved  for  the  life  of  an  EA  system,  the  architecture  or 
CONOPS  must  indicate  when  and  where  capability  improvements  are  expected.  The  OTA  can 
then  plan  episodic  events  and  subsequent  realistic  assessments  of  delivered  operational 
effectiveness  and  suitability. 

6.11.7  Findings  and  Recommendations 

•  An  adequate  CONOPS  and  operational  architecture  must  be  specified  as  part  the  Certification  of 
Readiness  for  OT&E 

•  The  current  ESC/TE  reinvigoration  of  T&E  should  be  supported  and  those  ESC  programs  without 
formal  TE-approved  test  plans  should  be  required  to  obtain  such  approval  at  an  early  date 

•  PEOs  and  DACs  should  ensure  that  acquisition  reform  initiatives  do  not  result  in  less-than- 
adequate  DT 

•  T&E  procedures  specifically  tailored  to  support  EA/SD  should  be  developed  and  published  by 
HQ  U.S.  Air  Force 

6.12  Infrastructure  for  Development  and  Integration 

A  major  discussion  and  requirement  regarding  actual  implementation  of  our  recommendations 
has  been  left  until  this  section.  Any  major  enterprise  normally  capitalizes  a  set  of  facilities  and 
operates  a  set  of  functions  that  allow  it  to  pursue  its  business.  In  the  case  of  information 
technology-oriented  organizations,  these  are  the  testing  and  integration  facilities,  and  the  IT- 
unique  evaluation,  estimation,  planning,  architecting,  and  simulation  capabilities  necessary  to  the 
successful  prosecution  and  integration  of  systems  in  this  rapidly  changing  environment.  In  the 
early  days  of  acquisition  of  aircraft,  the  military  invested,  and  still  does,  in  major  simulation  and 
evaluation  capabilities — in  the  Air  Force  principally  at  Wright-Patterson,  Eglin,  and  Edwards 
AFBs.  In  addition,  with  the  inception  of  major  new  technologies  in  recent  years,  very  significant 
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new  investments  were  made  in  signature,  electronic  warfare,  and  other  lethal  and  non-lethal 
evaluation  capabilities — often  Government  owned  and  operated. 

For  some  reason  “the  system”  in  the  Air  Force  has  not  perceived  the  need  for  similar  investment 
in  the  rapidly  evolving  and  high  leverage  field  of  information  technology.  Our  C2  systems  are 
therefore  developed  on  a  piecemeal,  contractor-oriented  basis,  leading  to  the  very  stovepipes  we 
are  trying  so  assiduously  to  avoid.  Facilities  such  as  the  Modeling,  Analysis,  and  Simulation 
Center  (MASC)  and  C2  Unified  Battlespace  Environment  (CUBE)  at  ESC  have  literally  been 
bought  with  savings  on  the  base  electric  and  heating  bills  when  winters  were  unexpectedly  mild. 
Hardly  the  way  to  run  a  business!  Indeed,  the  operating  Commands  have  in  all  cases  established 
capabilities  which  are  much  superior  to  anything  that  the  C2  development  community  has — and 
it  has  been  done  mostly  with  O&M  money. 

If  we  want  to  continue  the  stovepiping  of  Air  Force  C  ,  then  that  is  the  way  to  go  about  it — to  let 
the  operating  commands  “do  their  own  thing”.  We  have  done  a  top-level  estimate  of  the  kind  of 
annual  budget  that  should  be  provided  to  an  organization  such  as  ESC  to  allow  it  to  operate  in  a 
fashion  similar  to  the  DISA’s  JIEO  (see  6.5.1  above).  A  separate  program  element  and  budget, 
starting  at  approximately  $66  million  and  leveling  at  $60  million  annually  should  be  instituted, 
advocated  and  defended  by  the  Commander,  AFMC,  to  allow  ESC  to  build  and  maintain  a 
proper  infrastructure  to  accomplish  its  job.  This  would  allow  establishment  of  the  following 
capabilities  to  support  Air  Force  C2  evolution: 

1.  Enterprise  and  Domain  Architectures:  Development/Sustainment 

Realizing  an  integrated  C2  system  with  a  common  infrastructure  depends  upon  an  overall 
scoping  and  definition  of  capabilities  that  minimize  duplication  and  maximize  mutual  utility 
among  the  capabilities.  This  is  a  key  role  of  “architecture.”  Specifically,  AFI  33-124,  Enterprise 
Information  Technology  Architectures,  recognizes  three  levels  of  architecture:  enterprise,  domain 
and  program.  The  DoD  C4ISR  Architecture  Framework  specifies  the  fonnat  for  the  products 
expressing  military  architectures.  Responsibility  for  these  architecture  products  resides  with  the 
MAJCOMs  and  acquisition  agencies  (per  AFI  33-124).  ESC  and  AC2ISRC,  as  the  principal 
centers  responsible  for  C  ,  must  prepare  and  coordinate  the  pertinent  architecture  products  for  the 
integrated  C2  system  and  its  infrastructure. 

2.  Integration  and  Interoperability  (I&I):  Assurance  and  Certification  Testing  Development 

It  is  necessary  to  have  a  state-of-the-art  facility  (CUBE)  to  support  the  development,  integration, 
test,  certification,  and  sustainment  of  integrated  and  interoperable  C  weapon  systems  for  the  Air 

Force  and  DoD.  The  CUBE  is  augmented  with  a  state-of-the-art  MASC  facility  to  support  the 

2 

development,  integration,  test,  certification,  and  sustainment  of  integrated  and  interoperable  C 
weapon  systems.  These  capabilities  provide  the  basis  for  implementing  Simulation  Based 
Acquisition  as  an  integral  part  of  building  in  integration  and  interoperability  to  the  IC“  from  the 
beginning  of  a  new  program  or  modification  of  an  existing  system.  In  addition  these  capabilities 
provides  the  Air  Force  Linkage  to  the  Joint  Distributed  Engineering  Plant  for  integration  of  Air 
Force  C2  systems  with  Navy  and  Army  C2  elements  and  supports  formal  interoperability 
certification  and  testing  activities  for  Air  Force  C  systems. 

3.  Collaborative  Tools  in  Support  of  Infrastructure  Definition/Development 
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Infrastructure  definition  and  development  cannot  be  a  stovepipe  activity.  It  requires  considerable 
interaction  among  all  Air  Force  developers,  testers,  sustainers,  and  the  user.  Also,  given  the  vast 
scope  and  amount  of  information  needed  it  must  have  automated  support.  The  state  of 
collaborative  tools  is  such  that  we  can  take  advantage  of  them  to  assist  in  this  activity. 

In  order  to  coordinate  activities  across  warfighters,  developers,  testers,  and  sustainers  there  is  a 
huge  requirement  to  have  information  updated  and  current.  Use  of  portal  technology, 
collaboration  tools  will  allow  this  information  sharing.  It  may  also  allow  an  online 
troubleshooting  capability,  help,  and  configuration  management  of  the  infrastructure.  Building 
on  other  activities  such  as  the  JBC  collaborative  tools  evaluation  and  the  Air  Force  Portal 
development.  This  task  will  allow  the  development  of  a  collaborative  capability  for  coordination 
of  infrastructure  activities. 

4.  Information  Assurance  (IA)  Support 

The  need  for  effective  IA  measures  has  been  demonstrated  many  times  recently,  as  a  result  of 
virus  and  hacker  attacks.  In  order  to  respond  to  these  attacks,  the  Air  Force  needs  a  coordinated 
effort  across  all  the  systems  that  comprise  its  Integrated  C  enterprise.  The  purpose  of  this  set  of 
tasks  is  to  define  and  execute  that  coordinated  effort. 

Implementation  of  IA  in  Air  Force  systems  should  be  executed  in  accordance  with  the  DoD 
Defense  in  Depth  concepts  and  principles  in  order  to  protect  the  entire  Integrated  C  enterprise  at 
minimum  cost.  In  addition,  this  implementation  must  be  accomplished  in  a  coordinated  fashion 
among  all  systems  that  make  up  the  IC  enterprise  by  developing  a  vision  architecture  and 
program  roadmaps.  Finally,  we  have  to  ensure  the  products  that  are  fielded  are  adequately  tested 
to  avoid  interoperability  problems  and  are  accompanied  with  guidance  for  field  personnel  on 
their  use. 

5.  Commercial  Technology  and  Innovation  Exploitation 

Realizing  an  integrated  C2  system  built  on  a  common  (supporting)  IT  infrastructure  depends 
upon  the  continuing  discovery  and  exploitation  of  emerging  commercial  information 
technologies  and  innovative  approaches  to  mission  satisfaction.  The  demands  on  C4ISR  system 
developers  are  increasing  rapidly  due  both  to  a  changing  threat  environment  and  the  desire  to 
gain  military  advantage  through  the  use  of  advanced  technologies.  However,  while  advances  in 
IT  have  great  potential,  they  place  great  burdens  on  developers  to  realize  that  potential  while 
using  immature  and  in  many  cases  unproven  products.  In  addition,  these  new  technologies  must 
be  coupled  with  older  (legacy)  systems. 

Specifically,  exploiting  commercial  technology  and  experimental  innovation  in  support  of 
Integrated  Command  and  Control  System  realization  requires  investment  in  eleven  (11)  primary 
areas  as  follows: 

•  Web  technologies 

•  Personal  information  services 

•  COE  migration  to  “all”  COTS 

•  JBI  realization 

•  Portal  development 

•  Wireless/mobile  computing-communications 
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•  Advanced  knowledge/decision  management  aides 

•  Public  key  infrastructure 

•  Standards  committee  influence/participation 

•  Commercial  IT  giants  liaison  (MS,  Sun, . ) 

•  Joint  Technical  Architecture-Air  Force  emerging  standards  identification/analysis/support 

Funding  Summary.  Initial  estimates  of  the  annual  costs  to  implement  and  sustain  the  above- 
defined  infrastructure  elements  are  as  follows: 

Table  6-1.  Annual  Cost  Estimates  of  Infrastructure  Elements 


Infrastructure  Elements 

FY02 

FY03 

FY04 

FY05 

FY06 

FY07 

SYDP 

1.  Enterprise  and  domain  architectures: 
development/sustainment 

7.0 

7.0 

7.0 

7.0 

7.0 

7.0 

42.0 

2.  I&l:  assurance  and  certification  testing 
development 

24.2 

23.5 

22.5 

22.0 

22.0 

22.0 

136.2 

3.  Collaborative  tools  in  support  of 
infrastructure  definition/development 

4.0 

2.7 

0.8 

0.8 

0.8 

0.8 

9.9 

4.  IA  support 

7.8 

5.8 

5.8 

5.8 

5.8 

5.8 

36.8 

5.  Commercial  technology  and  innovation 
exploitation 

23.0 

23.0 

23.0 

23.0 

23.0 

23.0 

138.0 

Totals 

66.0 

62.0 

59.1 

58.6 

58.6 

58.6 

362.9 

Dollars  in  Millions 


6.13  Summary 

The  Air  Force’s  attention  to  an  appropriate  structure  to  acquire  command  and  control  systems  is 
far  from  sufficient.  The  process,  from  the  attention  at  Air  Staff  level,  through  the  PE  and  panel 
structure,  and  most  importantly  in  the  actual  approach  to  executing  acquisitions  once  the  overly 
ponderous  requirements  and  program  initiation  process  is  finished  is  seriously  broken. 

By  way  of  example,  the  process  used  by  the  Air  Force  on  the  TBMCS  Program  was  much  more 
painful  and  traumatic  than  it  needs  to  be.  The  process  used  by  a  number  of  other  programs  in  the 
DoD,  exemplified  by  the  GCCS  Evolutionary  Integration  process — where  an  annual  increment 
of  capabilities,  already  developed  in  laboratories,  ACTDs,  etc.,  in  accordance  with  a  set  of 
standards  (for  example,  the  DII  COE)  allowing  efficient  and  rapid  integration  into  an  evolving 
C2  system  (for  example,  GCCS),  best  satisfies  the  desired  attributes  for  acquisition  of  a  major  C2 
system.  The  Air  Force  acquisition  community  has  not  adopted  this  sort  of  approach  for  reasons 
unknown — in  fact  the  requirement  to  adhere  to  standards  such  as  the  DII  COE  has  been  seen  as  a 
costly  and  unnecessary  one.  As  long  as  this  attitude  persists,  we  will  continue  to  have  painful 
and  expensive  C2  acquisitions. 

6.14  Summary  of  Findings 

•  There  is  no  clear  focal  point  for  Air  Force  C2,  much  less  for  TACCS,  at  the  Air  Staff  level  (and 
explicitly  on  the  Air  Force  Council). 
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•  There  is  no  clear  definition  of  the  TACCS.  CONOPS  and  operational  architectures  are 
inadequate.  There  is  no  written  statement  of  a  TACCS  vision  nor  is  there  a  prioritized  list  of 
desired  capabilities. 

•  A  cumbersome  formal  Air  Force  requirements  process  hampers  responsiveness  to  user  needs  and 
technology  push.  AFI  63-123  (spiral  development)  addresses  this  issue,  but  retains  the  time- 
consuming  process  of  AFI  10-601. 

•  Neither  AF/TE  nor  AFOTEC  have  published  a  clear  statement  of  policy  regarding  OT&E  of 
evolutionary  acquisition  systems. 

•  The  PE  structure  for  the  TACCS  is  fragmented. 

•  Two  large  C2  systems,  TBMCS  and  Air  Force  Mission  Support  System,  have  had  significant 
performance  and  delivery  problems.  Precursor  systems  were  originally  developed  in  the  CAF 
and  handed  off  to  SAF/AQ  and  AFMC.  Inadequate  systems  engineering  was  done  on  these 
systems  at  the  outset — the  objective  was  to  satisfy  severe  capability  needs. 

•  The  existing  Air  Force  instruction  on  spiral  development  does  not  provide  adequate  guidance  to 
the  field.  The  practice  of  spiral  development  in  Air  Force  SPOs  is  ad  hoc  and  not 
institutionalized. 

•  There  is  no  spokesman  or  advocate  for  C2  infrastructure,  such  as  building  a  global  grid  or 
defining  standards  for  information  exchange. 

•  The  Chief  of  Staff  of  the  Air  Force  (CSAF)  has  no  reporting  system  or  metrics  scheme  which 
provide  an  assessment  of  Air  Force  progress  toward  accomplishment  of  an  effective  TACCS. 

•  Operators  and  users,  as  represented  by  the  AC2ISRC,  do  not  demonstrate  an  appreciation  for 
crucial  infrastructure  issues  such  as  the  DII  COE  and  Global  Grid. 

•  Combat  support  elements  (for  example,  supply,  maintenance,  finance,  medical,  etc.)  are  not 
adequately  considered  when  developing  TACCS  capability. 

•  The  acquisition  structure  for  the  TACCS  comprises  2  PEOs  and  1  DAC.  This  fragmentation 
precludes  coherent  acquisition. 

6.15  Recommendations 

•  SAF/AQ,  AFMC,  and  AC2ISRC  should  adopt  an  acquisition  approach  for  the  evolution  of  C2 
systems  such  as  TBMCS,  based  on  DISA  implementation  of  evolutionary  acquisition  for  GCCS. 
The  major  elements  are: 

-  Establishment  of  configuration  control  and  integration  capability  (AFMC,  SAF/AQ) 

-  The  capability  to  identify  (annually)  mission  application  improvements  needed  in  the  core 
TACCS,  to  identify  and  evaluate  candidate  (already  developed)  applications,  and  to  initiate 
developments  where  they  are  needed  (AC2ISRC) 

-  Sustainment  funding  for  integration  of  mission  applications  into  the  TBMCS  (mostly  3400 
and  3080)  (AFMC  and  SAF/AQ) 

•  SAF/AQ  should  avoid  “big  bang”  C2  acquisition  programs. 

•  HQ  Air  Force  should  publish  requirements  guidance  which  supports  the  dynamic  nature  of 
evolutionary  acquisition. 

•  AC2ISRC  should  be  tasked  to  accelerate  development  and  publication  of  the  definitive  vision, 
CONOPS  and  operational  architecture  for  Air  Force  TACCS. 

•  CONOPS’  and  operational  architectures  approved  by  the  sponsoring  MAJCOM  Commander 
must  be  required  before  starting  development.  An  adequate  CONOPS  and  operational 
architecture  must  be  specified  as  part  the  Certification  of  Readiness  for  OT&E. 


6-35 


•  CSAF  should  enjoin  MAJCOMs  from  organic  developments  of  C2  systems  without  consideration 
of  Air  Force-wide  system  impacts. 

•  CSAF  should  strengthen  C2  advocacy  on  the  Air  Force  Council.  A  single  focal  point  is  also 
needed  to  work  C2  issues  with  DoD,  Army,  Navy,  and  the  Joint  Staff.  CSAF  should  also  task  this 
advocate  with  the  responsibility  of  developing  and  implementing  a  reporting  system  which 
characterizes  C2  readiness  and  progress. 

•  The  Secretary  of  the  Air  Force/CSAF  should  institutionalize  the  functions  of  the  Air  Force  CIO  to 
provide  the  advocacy  and  responsibilities  required  by  the  Clinger-Cohen  Act  and  to  be  the 
spokesman  for  the  C2  infrastructure. 

•  SAF/AQ  should  consolidate  the  TACCS  programs  into  a  single  (PEO  or  DAC)  portfolio  and 
under  a  single  Mission  Director.  SAF/AQ  should  also  develop  a  capstone  PMD  to  relate  and 
prioritize  all  those  system  PMDs  which  constitute  the  TACCS.  It  may  also  be  useful  to  take  the 
following  actions: 

-  Establish  metrics  to  measure  the  effectiveness  of  the  current  PEO  management  system  as 
opposed  to  the  DAC  having  C2  system  responsibility 

-  Stabilize  assignments  of  PEO/PMs  to  match  milestone/delivery  achievements 

•  AF/XP,  with  SAF/AQ  and  AC2ISRC,  should  restructure  the  program  elements  which  constitute 
the  TACCS  into  a  relatively  small  number  of  individually  high  value  PEs  which  focus  on  the 
nodes  of  the  TACCS,  their  combat  capability  interrelationships,  and  their  evolutionary 
development. 

•  SAF/AQ  should  task  SEI  and  ESC  to  develop  a  CMM  for  EA/SD  leading  to  a  revised  AFI  and 
formal  EA/SD  training.  AFMC  should  develop  and  implement  EA/SD  training  for  the 
Acquisition  Corps. 

•  EA/SD  demands  an  integrated  effort  of  not  just  the  operational  testing  community,  but  the 
developmental,  contractor  and  user  test  communities.  AF/TE  and  AFOTEC  should  develop,  in 
cooperation  with  ESC/TE,  approaches  that  enhance  and  support  EA/SD  acquisition.The  current 
ESC/TE  reinvigoration  of  T&E  should  be  supported  and  those  ESC  programs  without  formal 
ESC/TE- approved  test  plans  should  be  required  to  obtain  such  approval  at  an  early  date. 

•  T&E  procedures  specifically  tailored  to  support  EA/SD  should  be  developed  and  published  by 
HQ  Air  Force. 

•  Designate  a  champion  for  GCSS-AF,  coordinate  and  approve  the  lead  agency  charter  amendment, 
approve  resources  for  this  lead  agency,  establish  a  single  acquisition  management  organization, 
direct  that  all  Air  Force  combat  support  systems  integrate  into  GCSS-AF  and  comply  with  its 
standards. 
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Appendix  6A 
Acquisition  Panel  Charter 


The  Acquisition  Panel  will: 

•  Identify  the  desired  attributes  of  an  acquisition  process  to  acquire  and  evolve  components  of  the 
Joint  Tactical  Air  Command  and  Control  System — with  special  attention  to  the  decision-aiding 
system(s)  supporting  the  AOC(s).  The  principal  components  of  the  Joint  Tactical  Air  Command 
and  Control  System  are: 

-  Sensors  and  sources  of  data 

-  Communication  links 

-  The  Joint  Air  Operations  Center  and  associated  Air  Operations  and  Control  Centers  (for 
example,  AWACS,  Wing  Operations  Center) 

-  Weapons  delivery  and  support  systems 

•  Work  closely  with  the  System  Definition  Panel  to  ensure  the  operators’  needs  are  addressed. 

•  Document  the  current  Air  Force  acquisition  process  being  used  to  acquire  systems  such  as 
TBMCS.  Investigate  alternate  acquisition  processes,  DoD,  and  other  (for  example,  commercial), 
which  may  be  more  appropriate  for  acquiring  the  TACCS.  Evaluate  these  processes  against  the 
attributes  described  in  first  bullet  above. 

•  Describe  an  appropriate  acquisition  process  to  acquire  and  evolve  the  TACCS — including 
incorporating  the  JBI  concept. 

•  Recommend  changes  to  current  Air  Force  processes  to  more  closely  approximate  the  attributes  of 
third  bullet  above.  Identify  near  term  and  longer-term  actions  required. 

Coordinate  with  other  panels  where  technologies,  personnel  actions,  etc.  are  needed  or 
recommended. 
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Chapter  7 

Linking  the  Air  Force  by  2005 


7.1  Introduction 

The  Study  was  given  the  assignment  to  look  at  the  solutions  to  “link  the  Air  Force  by  2005”  with 
specific  reference  to  the  difficulty  in  attacking  mobile  targets  in  Kosovo,  as  well  in  other  recent 
crises.  We  established  teams  to  look  at  the  time-critical  targeting  (TCT)  problem  generally,  as 
well  as  the  datalink  problem  in  particular,  with  the  goal  of  reducing  TCT  timelines  from  hours  to 
minutes. 

7.2  Time-Critical  Targeting  Timelines 
7.2.1  Contributions  to  Reduce  TCT  Timelines 

Recent  conflicts  have  highlighted  the  difficulties  in  rapidly  attacking  time-critical  targets.  The 
timeline  from  recognition  of  the  existence  of  a  targetable  object  until  the  kill  is  excessively  long. 
Experience  in  Operations  Desert  Shield,  Desert  Storm,  and  Noble  Anvil  (Kosovo)  showed  that 
timelines  of  4+  hours  were  typical.  The  goal  expressed  by  the  leadership  is  to  reduce  the  time 
from  target  detection  to  target  strike  to  under  10  minutes  from  the  current  multiple  hours.  The 
Air  Force  Scientific  Advisory  Board  (SAB)  has  identified  and  prioritized  solutions  to  bring  the 
timeline  down  to  this  goal. 

Figure  7-1  portrays  the  current  and  future  timeline  for  targeting  time-critical  targets  as 
experienced  in  Kosovo.  Data  for  the  U-2S  sensor  processing,  exploitation,  dissemination 
process  was  based  on  analysis  of  the  image  analyst  and  mensuration  logs  at  the  Distributed 
Common  Ground  System  (DCGS)  at  Beale  Air  Force  Base  (AFB)  and  the  20th  Intelligence 
Squadron  at  Offutt  AFB  by  Adroit  Systems  under  contract  to  the  Air  Force  Studies  and  Analyses 
Agency.  The  times  attributed  to  the  operational  high-level  coordination,  Combined  Aerospace 
Operations  Center  (CAOC)  nomination,  target  folder  preparation,  and  attack  execution  phases 
were  mostly  anecdotal  information  gathered  by  the  SAB  from  experienced  intelligence, 
surveillance,  and  reconnaissance  (ISR)  officers  present  at  the  CAOC.  The  best  time  case 
indicated  is  based  on  strike  missions  using  an  F-15E  with  a  Joint  Standoff  Weapon  from  combat 
air  patrol  position  with  target  folder  infonnation  relayed  by  data  link  direct  to  the  F-15E  pod. 
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Figure  7-1.  TCT  Targeting  Timeline — Now  and  Future 


7.2.2  Major  TCT  Timeline  Findings 

The  analysis  of  the  time-critical  targeting  experience  led  the  Study  to  the  following  findings: 

•  Enhanced  sensor  coverage  (time,  space,  and  phenomenology)  is  essential.  High-altitude,  long- 
endurance  unmanned  aerial  vehicle  (UAV)  systems  are  sufficiently  proven  and  in  many  regions 
can  provide  performance  like  low  Earth  satellites.  They  are  the  only  near-term  answer  for 
standoff  (7  x  24)  ISR  coverage  necessary  for  defense  against  time-critical  targets. 

•  Technology  for  modular  active  electronic  scan  antenna  (AESA)  ground  moving-target  indication 
(GMTI)/synthetic  aperture  radar  (SAR)  has  been  developed  under  the  F-22  and  Joint  Strike 
Fighter  (JSF)  programs  and  is  ready  for  development  and  production  for  surveillance  platforms. 

•  The  technology  of  moving-target  exploitation  (MTE)  tools  for  target  recognition  and  tracking  has 
achieved  significant  progress  but  needs  maturing  and  further  demonstration  using  AESA 
hardware. 

•  The  combination  of  advanced  GMTI,  high-range-resolution  target  features  and  interleaved, 
simultaneous  spot  (ultrahigh  resolution  [UHR++])  SAR  images  from  the  same  platform  will 
revolutionize  ISR  and  significantly  reduce  the  tasking,  collection,  processing,  exploitation,  and 
dissemination  over  that  of  current  wide-area  imagery  schemes. 

•  Foliage  penetration  (FOPEN)  GMTI/SAR  ultrahigh-frequency  (UHF)  radar  technology  is 
available  for  use  as  a  complementary  system  with  a  microwave  AESA  GMTI/SAR  system. 
Significant  sharing  of  common  hardware  is  possible.  It  is  the  only  system  that  will  provide 
standoff  coverage  in  forested  regions.  It  requires  more  maturation. 

•  Advances  in  data  exploitation  (fusion)  are  required  for  robust  capability.  The  technology  of 
fusion  processes  for  timely,  geo-registered  multisensor  inputs  from  satellite,  aircraft,  and 
unattended  ground  sensors  has  matured.  This  includes  high-resolution  SAR/electro-optical  (EO)/ 
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infrared  (IR)  imagery,  moving-target  indication/MTE  radar,  signals  intelligence  (S1GINT),  and 
hyperspectral  signatures.  Some  capabilities  are  in  the  pipeline  but  need  testing  and  fielding 
(MTE,  automatic  target  recognition),  and  additional  capabilities  need  to  be  developed  for  this 
focused  fusion  capability.  Currently  fielded  sensor  control  and  fusion  capabilities  are  inadequate 
for  future  Air  Force  operations  in  timeliness,  accuracy,  and  completeness.  There  are  some 
emerging  fusion  (GMTI  tracking,  all-source  track  fusion)  and  sensor  tasking/management 
capabilities  (multi-asset  synchronized  planning)  that  offer  enhancements. 

Although  these  are  still  short  of  ultimate  needs  in  fusion  and  control  and  in  their  ties  to  dynamic 
planning  and  execution.  Presentation  and  visualization  of  fused  info-products  is  a  neglected  area 
and  there  exists  no  organized  effort  to  codify  or  quantify  what  capabilities  are  available  for 
fusion.  Codification  and  quantification  are  essential  in  order  to  assess  areas  for  further  science 
and  technology  investment  and  to  determine  needs  for  new  or  augmented  sensing  capabilities. 

The  technology  that  enables  automated  target  mensuration  of  any  imagery  with  features  by  co¬ 
registering  it  with  a  precision  digital  reference  imagery  and  terrain  elevation  database  has 
matured.  Further  reference  development  will  provide  target  geo-registration  to  Earth  coordinates 
of  a  meter  or  so  and  significantly  change  and  speed  the  mensuration  process. 

Sensor  management  problems  will  be  magnified  in  the  TCT  context.  Semiautomatic  tools  to  aid 
real-time  ISR  sensor  and  platform  planning  and  tasking  have  lagged. 

Semiautomatic  aids  and  processes  to  do  target  analysis,  mensuration,  coordination,  and 
nomination  in  parallel  are  vitally  needed  and  are  key  to  speeding  up  time-critical  targeting. 
Dedicated  time-critical  target  cells  and  processes  are  required  (tools,  tactics,  techniques, 
procedures,  training  ...). 

Battle  damage  assessment  is  a  comparatively  underdeveloped  capability  within  the  larger  (and 
itself  underdeveloped)  area  of  real-time  fusion  for  operations.  Combat  assessment  tools — that  is, 
tools  for  combined  battle  damage  assessment  and  responsive  tasking — do  not  exist  except  as 
created  individually  by  operators.  This  represents  an  area — namely,  fusion  of  information  and 
dynamic  planning — that  cuts  across  standard  functional  boundaries.  Tools  and  processes  to 
provide  coordinated,  near-real  time  combat  damage  assessment,  are  needed  from  all  imagery, 
including  SAR  and  EO,  strike  aircraft  video,  ground  target  motion  (or  cessation  thereof),  and 
pilot  reports. 

Use  of  advanced  high-power,  high-gain  AESA  radar  systems  to  provide  selective,  high-power 
spot  jamming  for  electronic  countermeasures  (ECM)  support  is  feasible  but  requires  dynamic 
sensor/jammer  tasking,  planning,  and  management. 

Automated  in-flight  target  folder  preparation  and  update  tools  and  secure  real-time  data  links  to 
strike  aircraft  are  required  for  dynamic  targeting  of  time-critical  targets. 

Continued  development  of  wideband  communications  beyond  line  of  sight  to  support  remote 
reachback  analysis  is  needed. 

Intelligence  preparation  of  the  battlefield  (IPB)  is  critically  important  to  sensor  planning,  tasking, 
exploitation,  and  geo-registration.  The  role  of  IPB  is  changing  from  operations  planning  to  the 
more  continuous  process  needed  to  support  agile  and  dynamic  operations:  predictive  battlespace 
analysis  to  support  missions  such  as  time-critical  targeting  and  timely  precision  targeting 
information.  Based  on  a  worldwide  high-precision,  digital  foundation  database  of  imagery, 
digital  terrain  elevation  database,  digital  feature  analysis  data  (DFAD),  and  other  information,  it 
will  produce  terrain  delimitation  (probability  of  route  and  location  of  command  posts,  forces,  etc.) 
as  well  as  precision  geo-registration  reference. 

There  is  a  critical  need  for  a  complete,  dynamically  updated,  accurate  foundation  data 
environment  that  maps  the  battlespace:  ortho-rectified,  geo-registered  data  sets  and  automated, 
laborless,  database  maintenance. 
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•  High-speed  weapons  with  data  links  for  in-flight  retargeting  are  needed  for  striking  critical 
mobile  targets. 

•  There  is  no  current  capability  to  display  how  information  operations  (10)  can  affect  the  battlefield 
and  how  such  operations  can  offset  metal  on  target. 

7.2.3  Sensors  and  Platforms 

The  key  needed  ISR  improvement  is  to  have  continuously  available  and  readily  taskable  ISR 
platforms  that  can  stay  within  rapid  access  of  the  target.  High-altitude,  long-endurance  UAVs 
could  provide  7-day,  24-hour  ISR  coverage,  and  an  advanced  radar  could  provide  all-weather, 
wide-area  GMTI  coverage  and  moving-target  recognition  as  well  as  simultaneous,  interleaved 
high-resolution  SAR  spot  imagery. 

Today’s  ISR  systems  rely  heavily  on  radar  imagery  because  it  is  the  key  source  to  provide  the 
necessary  all-weather,  long-range  target  recognition  and  precision  location.  Imagery,  especially 
wide-area  imagery,  is  not  rapid  either  in  tasking,  collection,  processing,  exploitation,  or 
dissemination,  not  only  because  of  the  very  high  bandwidth  required  and  the  huge  data  files  to  be 
searched,  but,  more  important,  the  very  difficult  problem  involved  in  machine  image  recognition 
and  analysis.  Despite  30  years  of  research  and  development  in  machine  target  recognition  and 
the  tremendous  increase  in  computer  power,  we  have  not  achieved  automatic  wide-area  image 
analysis  capability  and  have  just  begun  to  achieve  modest  semiautomated  tools  to  aid  expert 
human  image  interpreters.  The  excellent  work  done  over  the  years  in  automatic  image 
interpretation  and  target  recognition  has  convinced  the  community  that  goals  such  as  rapid 
automatic  scanning  of  100  square  kilometers  (sq  km)  per  minute  of  even  high-quality  imagery 
(NIIRS  6)  is  still  many  years  away.  Today  it  takes  at  least  an  hour  to  analyze  even  small 
10-square-kilometer  spot  images  and  provide  validated  target  information  and  mensurated  target 
coordinates. 

7.2.4  Advanced  AESA  GMTI/SAR 

New  advanced  GMTI/SAR  sensors  offer  significant  breakthroughs  in  real-time  detection, 
accurate  location,  and  target  feature  information  of  moving  targets;  the  breakthroughs  can 
provide  the  real-time  cue  needed  to  take  high-resolution  spot  imagery  needed  for  the  targeting 
process.  This  moving-target  detection  process  is  the  experience  of  every  deer  hunter  who  is 
often  blind  to  stationary  targets  but  is  rapidly  cued  by  even  the  slightest  motion  by  the  deer. 

Once  cued,  the  hunter  is  able  to  focus  precisely  on  the  target.  Advanced  GMTI  radar  can 
provide  the  needed  wide  area  surveillance  for  moving-target  detection  and  recognition  and  can 
provide  integrated  simultaneous  multiple-SAR  spot  image  capability.  Unlike  imagery,  the 
information  from  a  GMTI  radar  produces  only  very  modest  data  rates  and  can  be  automatically 
processed  and  analyzed  in  real  time. 

The  advanced  radar  technology  is  an  outgrowth  of  the  AESA  technology  developed  for  the  F-22 
and  JSF  fighter  programs  and  now  being  applied  to  the  radar  technology  improvement  program 
(RTIP).  A  modular,  scaled  variant  of  the  AESA  radar  will  have  the  power  and  bandwidth  to 
provide  continuous  tracking  of  thousands  of  targets  with  automatic  recognition  of  vehicles  and 
military  units.  It  would  be  capable  of  simultaneous  interleaved  GMTI  and  UHR  SAR  modes. 

The  dynamic  GMTI  picture  of  enemy  force  movement  with  simultaneous  high-range-resolution 
(HRR)  target  features  would  be  able  to  identify  target  regions  for  cued,  interleaved  SAR 
stationary  target  imagery.  The  estimated  GMTI  update  rates  for  an  area  of  5  sq  km  to  10,000  sq 
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km  is  expected  to  be  in  the  order  of  10  to  20  seconds  per  update  for  average  radiated  power  of  3 
to  6  kW.  This  would  allow  simultaneous  1-2  interleaved  SAR  spot  images  and  hundreds  of 
target  recognition  measurements  without  degrading  GMTI  coverage.  The  cued  SAR  spot  mode 
would  be  capable  of  improved  high-resolution  imagery,  which  would  allow  rapid  image 
exploitation  and  target  recognition. 

The  target  tracking  accuracy  and  probability  of  track  continuity  depends  heavily  on  target 
acceleration,  foliage,  terrain  shadowing,  traffic  density,  the  number  of  intersecting  roads,  etc. 
However,  the  targeting  process  can  predict  some  of  these  factors  from  IPB  terrain  and  feature 
data  and  can  schedule  updates  when  targets  reach  more  favorable  conditions  or  cease  motion  and 
allow  a  SAR  image.  When  conditions  improve,  the  dynamic  nature  of  the  GMTI/HRR  and  spot 
SAR  can  resolve  ambiguities  and  achieve  track  or  fixed  location  accuracy  necessary  for  weapon 
attack. 

This  significant  technical  advancement  in  GMTI  radar  will  provide  a  major  leap  ahead  in  the 
quality  and  timeliness  of  battlefield  reconnaissance  for  the  dominant  battlespace  awareness 
needed  by  the  battle  commander.  Rather  than  just  slowly  updating  moving  dots,  advanced 
GMTI  radar  systems  will  provide  high-update  moving-target  detection  and  individual  target 
features,  providing  much  higher-quality  information  about  the  nature  and  dynamics  of  thousands 
of  moving  targets  over  large  areas.  The  knowledge  of  vehicle  features  coupled  with  high-update 
track  data  provides  significant  information  concerning  military  unit  convoy  characteristics  such 
as  number,  type,  and  mix  of  vehicles;  vehicle  traffic  and  passing  activities  as  a  function  of  road 
type;  mix  of  civilian  and  military  traffic;  indications  of  roadblocks,  bridges,  or  other  traffic 
constrictions;  associated  helicopter  movement;  congregation  of  vehicles  at  areas  that  can  be 
command  posts  or  logistics  or  refueling  areas;  traffic  sources  such  as  known  military 
installations;  and  traffic  sinks  or  destinations  that  can  be  associated  with  military  units. 

GMTI  radar  high-update  detections  coupled  with  rapid  vehicle  feature  information  is 
significantly  different  from  imagery.  Finding  stationary  enemy  targets  in  large  areas  with  high- 
resolution  (at  20  to  200  Mbits  per  second)  imagery  can  overwhelm  the  exploitation  task  and 
requires  large  numbers  of  highly  trained  human  image  analysts  to  exploit  it.  Advanced  dynamic 
GMTI  radar  detection  and  associated  high-resolution  target  feature  information  is  a  fairly  low- 
data-rate  infonnation  stream  (hundreds  of  Kbits  per  second  to  a  few  Mbits  per  second,  depending 
on  vehicle  count)  that  can  be  processed  automatically.  GMTI  track  data  lends  itself  to 
background  automated  analysis  tasks  such  as 

•  Counting  the  number  of  vehicles  as  a  function  of  areas  or  boundaries 

•  Determination  of  sources  of  target  vehicles  and  their  destinations,  including  the  road  or  path 
taken 

•  History  of  movement  over  time 

•  Target  evidence  and  recognition  feature  accrual  and  comparison  over  time,  not  just  a  single 
detection 

Microwave  GMTI/SAR  give  all-weather  performance  but  are  unable  to  penetrate  foliage. 

FOPEN  radar  and/or  unattended  ground  sensors  (UGS)  and  covert  radar  tags  are  a  necessity  if 
foliage  is  prevalent  and  the  enemy  is  skilled  in  employing  camouflage,  concealment,  and 
deception.  Recent  work  holds  the  promise  of  supplementing  the  microwave  systems  with  shared 
receiver,  exciter,  and  processing  hardware  operating  in  the  UHF  band  and  capable  of  foliage- 
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penetration  GMTI.  Such  multirole  radars  would  provide  cost-effective  sensors  for  long- 
endurance  UAVs.  The  microwave  frequency  would  be  employed  in  open  terrain,  the  UHF  in 
foliated  regions.  The  two  would  cue  dynamic  management  of  the  two  radars  and  their 
SAR/GMTI  modes. 

7.2.5  Intelligence  Preparation  of  the  Battlefield 

IPB  is  a  process  to  analyze  the  battlefield  based  on  a  priori  collected,  geo-registered,  and 
analyzed  intelligence,  such  as  imagery  intelligence  (SAR,  visual  and  multispectral),  SIGINT, 
human  intelligence,  and  measures  and  signatures  intelligence.  Future  IPB  can  provide 
significantly  more  intelligence  support  to  the  commander  than  is  currently  possible.  Now  IPB  is 
driven  by  operational  plan  execution.  Targeting  and  target  folder  development  begin  with  an 
execution  (deployment)  order,  and  shortening  the  time  to  employment  can  squeeze  out  target 
folder  update  opportunities.  Future  IPB  will  need  to  become  continuous  both  before  and 
throughout  a  conflict  and  become  plan-driven  for  collection  tasking  in  order  to  provide 
continuous  database  maintenance. 

The  key  to  modern  IPB  is  the  development  of  a  foundation  data  environment  that  includes 

•  Ortho-rectified  and  precisely  geo-registered  imagery  data  sets 

•  Imagery  from  all  sources  for  targeting,  geo-location,  and  feature  analysis 

•  Digital  elevation  models  for  targeting,  geo-location,  and  planning 

•  DFAD,  which  includes  hydrographic  and  foliage  features  and  cultural  or  man-made  features  such 
as  buildings  and  roads 

•  Integration  of  situational  awareness  data  such  as  military  installations  and  force  location 

•  Time  record  of  changes  and  the  effect  of  weather 

A  priori  products  produced  from  this  foundation  data  environment  include  terrain  delimitation, 
which  provides  analysis  of  avenues  of  motion  based  on  terrain  nature,  foliage,  water,  bridges, 
and  class  of  vehicle.  It  also  provides  the  digital  reference  infonnation  for  precision  geo¬ 
registration  of  tactical  imagery.  In  addition,  tactical  imagery  is  analyzed  against  the  database  to 
produce  large  object-level  changes  such  as  vehicles,  new  structures,  and  earth  movement.  A 
next  level  of  analyses  would  be  based  on  current  intelligence  information  on  location  of  forces, 
bases,  logistics,  enemy  objectives,  etc.  Based  on  this  analyses,  sensor  tasking  for  high- 
probability  regions  could  be  prepared  a  priori. 

Future  IPB  tools  must  become  automated  and  continuous  for  automated,  laborless  database 
maintenance  and  laborless  target  folder  development  and  maintenance. 

7.2.6  The  Benefit  and  Impact  of  Speeding  Up  the  Target  Attack  Decision  Process 

A  key  benefit  of  such  advanced  ISR  and  IPB  input  is  that  the  long-endurance,  high-altitude  radar 
produces  sufficient  real-time  accurate  target  location  and  quality  that  it  could  allow  the 
mensuration,  high-level  coordination,  and  target  nomination  processes  at  the  operations  center  to 
proceed  in  parallel  with  strike  approval  based  on  the  final  rapid,  high-resolution  image  analysis 
for  target  identification.  This  would  significantly  speed  the  time  for  putting  weapons  on  target 
compared  to  the  current  process,  which  is  highly  serial  out  of  necessity.  In  the  TCT  quick-strike 
process,  it  is  necessary  to  provide  automated  aids  and  hands-on  controls  for  the  warfighter 
charged  with  making  the  decision  as  to  when  the  available  information  warrants  committing 
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weapons  against  a  target  that  has  been  detected,  identified,  tracked,  and  mensurated.  It  seems 
intuitive  that  high-quality,  accurate,  track  data  and  moving-target  recognition  data,  appropriately 
fused  in  a  multiple-hypothesis  tracking  system  and  aided  by  interleaved  very  high-resolution  spot 
SAR  images,  can  provide  a  significant  step  toward  the  confidence  needed  in  order  to  proceed 
with  parallel  commitment  of  resources.  However,  the  process  of  making  that  decision  obviously 
involves  a  number  of  variables:  the  probability  that  the  target  is  indeed  a  TCT;  the  value  of 
destroying  that  target;  the  availability  of  assets  to  carry  out  the  attack;  the  existence  of  enemy 
defenses  that  threaten  each  such  asset,  and  the  probabilities  of  successful  mission  execution  and 
of  asset  loss  for  each;  the  rules  of  engagement,  such  as  guidelines  on  risk  of  collateral  damage, 
and  estimates  of  the  probability  of  such  damage  and  of  its  extent. 

This  closely  coupled,  parallel  process  raises  an  entire  range  of  questions  and  research  areas,  such 
as  what  information  should  be  presented  so  that  the  warfighter  can  make  a  decision  quickly  and 
correctly,  and  how  should  that  information  be  presented  in  order  to  provide  an  infonnation 
system  with  the  right  “handling  qualities”  for  the  warfighter?  What  decision  aids  are  useful  for 
the  warfighter?  Can  this  be  done  in  a  way  that  provides  the  same  sense  of  command  authority  to 
the  warfighter  that  digital  fly-by-wire  systems  provide  to  the  pilot? 

7.2.7  Recommendations 

From  the  discussion  above,  and  preliminary  analyses  conducted  by  the  Study,  the  following 
actions  can  result  in  a  significantly  shortened  TCT  timeline  and  hence  are  recommended: 

•  Accelerate  production  of  Global  Hawk  with  improved  electrical  power  (  Aeronautics  Systems 
Center  [ASCJ/RA) 

•  Develop  and  produce  family  of  modular  AESA  GMTI/SAR  surveillance  radars  for  Global  Hawk 
as  a  part  of  the  RTIP  development  (Electronic  Systems  Center  [ESC]/JS  with  Air  Force  Research 
Laboratory  [AFRL]/SN  and  ASC/RA) 

•  Mature  GMTI  radar  HRR  and  tracking  techniques  (AFRL/IF) 

•  Develop  GMTI  FOPEN  technology  for  shared  integration  with  microwave  AESA  systems  of  the 
future  (AFRL/SN) 

-  Continue  research  and  development  of  semiautomated  tools  for  target  recognition,  analysis, 
image  mensuration,  and  target  geo-registration  using  a  digital  foundation  reference  database 
(AFRL/IF  with  National  Imagery  and  Mapping  Agency  [NIMA]  and  the  Defense  Advanced 
Research  Projects  Agency  [DARPA]) 

•  Develop  fusion  technology  for  real-time  integration  of  imagery,  SIGINT,  UGS,  radar  tags,  and 
EO/IR/hyperspectral  (AFRL/IF) 

•  Continue  development  of  dedicated  TCT  cell  (tactics,  techniques,  procedures)  (  Aerospace 
Command,  Control,  Intelligence,  Surveillance,  and  Reconnaissance  Center  [AC2ISRC]) 

•  Analyze  the  status  of  techniques  and  aids  to  parallel  the  target  exploitation,  mensuration, 
coordination,  and  nomination  processes  (AC2ISRC/ESC/AFRL) 

•  Analyze  the  status  of  techniques  to  speed  sensor  planning  and  tasking  and  attack  planning  and 
execution  (  AC2ISRC/ESC/AFRL) 

•  Assess  the  development  and  role  of  the  Air  Force  in  the  foundation  database  for  IPB  and 
mensuration  (AFRL  with  NIMA,  National  Reconnaissance  Office) 

-  Assess  tools  for  automated  IPB 
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Develop  tools  for  automated  in-flight  target  folder  preparation  for  targeting  and  retargeting 
(AFRL/IF) 


•  Analyze  development  and  application  of  data  links  to  speed  strike  planning,  pilot  folder 
preparation  and  update,  weapon  (AC2ISRC/ESC/AFRL) 

•  Pursue  development  of  high-speed  weapons  with  data  links  for  in-flight  re-targeting  (AFRL  with 
DARPA) 

7.3  Data  Links 

The  “link  the  Air  Force  by  2005”  theme  provides  a  direct  challenge  for  the  aggressive 
implementation  of  datalink  program  and  an  indirect  challenge  for  the  datalinks  through  the 
associated  need  to  quickly  attack  time  critical  targets. 

In  the  late  1950s,  Air  Force  air  defense  fighters  depended  on  Semi-Automatic  Ground 
Environment  control  systems  and  datalinked  commands  to  effect  continental  air  defense.  First- 
and  second-generation  data  links  were  installed  in  hundreds  of  aircraft  to  allow  simple  messages 
relaying  target  data  from  ground-control  intercept  sites.  In  some  cases  the  ground  controllers 
actually  took  control  of  the  aircraft  (or  the  missile,  in  the  case  of  BOMARC)  and  completed  the 
intercept.  Over  time,  the  population  of  datalink-equipped  Air  Force  aircraft  shrunk  substantially. 
In  the  1991  SAB  Summer  Study,  “Offboard  Sensors  to  Support  Air  Combat  Operations,”  we 
strongly  recommended  that  the  Air  Force  realize  the  importance  and  leverage  of  airborne 
datalink  systems  and  develop,  fund,  and  manage  a  program  to  facilitate  the  transfer  of  data 
between  weapons  systems.  Yet,  during  that  same  year,  Air  Force  senior  leadership  declared  that 

TO 

datalinks  were  unnecessary  “because  of  doctrine.”  By  1996,  the  Air  Force  had  returned  to  a 
point  where  only  3  percent  of  aircraft  were  equipped  with  J-series  datalinks  (Tactical  Digital 
Information  Link  J  [TADIL-J]  and  Variable  Message  Format  [VMF]). 

Since  that  time,  the  use  of  Global  Positioning  System  for  navigation  and  weapons  delivery  has 
underlined  the  importance  of  digital  data  transfer  directly  from  computer  to  computer,  without 
the  difficult  process  of  voice  transfer  and  computer  entry  of  long  number  strings,  underscoring 
the  need  for  digital  data  links. 

Over  the  years,  the  SAB  has  repeatedly  addressed  the  aircraft  datalink.  The  past  SAB  studies 
have  continually  reminded  the  Air  Force  to  expedite  the  capability  for  transfer  of  digital  data  to 
and  among  aircraft.  The  1982  SAB  Summer  Study  on  “Enhancement  of  Military  Airlift”  made  a 
considerable  number  of  recommendations  for  the  transition  to  digital  data  and  the  user  of  data 
links  on  military  airlifters.  The  1991  Summer  Study,  “Offboard  Sensors  to  Support  Air  Combat 
Operations,”  noted  that  “combat  aircraft  should  be  equipped  with  digital  datalinks  suitable  for 
efficient,  countermeasures-protected,  low-error  information  transfer  to  aircraft  systems  and 
aircrews  at  modest  data  rates”  and  recommended  the  acquisition  of  the  Joint  Tactical  Information 
Distribution  System  (JTIDS),  Information  Dissemination  Management  (IDM),  and  other  radios 
with  the  appropriate  gateway  systems.  The  1994  Study,  “Communications  Technology  Options 
for  Global  Air  Operations,”  noted  that  “data  links  are  critical  to  future  air  operations,  imparting 
critical  situational,  threat,  and  target  information  to  the  warfighter,”  further  suggesting  that  the 
Air  Force  “view  the  data  transfer  architecture  as  a  mixture  of  cost-effective  radio  solutions 
interconnected  by  gateways.” 


38  “U.S.  Air  Force  Chiefs,  C31  Officials  Dispute  Need  for  F-15  Datalinks,”  Defense  News,  8  July  1991. 
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Figure  7-2  depicts  the  notional  architecture  developed  in  the  1994  Study.  The  1996  Study, 
“Vision  of  Aerospace  Command  and  Control  for  the  21st  Century,”  said,  “The  Air  Force  should 
move  away  from  the  heavy  reliance  on  voice  communications,  especially  to  the  cockpit,  and 
move  to  more  capable  linked  data  systems  such  as  Link- 16.”  The  1997  Study,  “Global  Air 
Navigation,”  noted  that  “data  link  transmission  provides  for  a  substantial  improvement  in  the 
effectiveness  of  information  transfer,  greatly  reducing  the  errors  and  confusion  associated  with 
voice  transmissions.  Moreover,  the  efficiency  is  similarly  much  greater,  probably  to  a  factor 
of  100: 1,  especially  those  data  transfer  actions  which  are  associated  with  the  transfer  of 
‘numbers’  related  with,  for  example,  target  location  and  character.” 
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Figure  7-2.  Envisioned  Datalink  Architecture 
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In  Joint  Expeditionary  Force  Experiment  2000,  we  were  able  to  hear  the  flight  lead  air  crews 
debrief  the  mobile  target  (time-critical  target)  attack  missions  with  nearly  universal  success  with, 
and  support  for,  use  of  the  variety  of  data  links  on  the  fighter,  bomber,  command  and  control 
(C2),  and  surveillance  aircraft  involved.  The  variety  of  datalink  systems  was  a  challenge,  but  the 
challenge  was  met  with  the  Talon  Gateway  system  developed  and  demonstrated  there  but  the 
Space  Warfare  Center.  The  key  message  was  that  datalinks  are  important  to  effective  air 
operations,  and  the  Air  Force  must  establish  a  serious  program  to  provide  data  transfer  capability 
to  and  among  aircraft. 

The  historic  lack  of  acceptance  of  data  links  has  not  slowed  their  development  to  support  special 
missions.  In  fact,  the  number  of  different  data  links  in  use  by  the  Air  Force  is  relatively  large. 
Tables  7-1  thru  7-4  list  many  of  those  in  current  use  across  the  Department  of  Defense  (DoD),  of 
which  the  Air  Force  uses  a  substantial  fraction.  Table  7-6  illustrates  the  commonality  that  is 
currently  planned  between  Air  Force  C2  systems  and  both  combat  aircraft  and  ISR  platforms. 

39  Adapted  from  the  1994  SAB  Study,  “Communications  Technology  Options  for  Global  Air  Operations.” 
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DoD  Directive  (DoDD)  4630.5  contains  basic  policy  regarding  command,  control, 
communications,  and  intelligence  (C3I)  compatibility,  interoperability,  and  integration,  which 
includes  C3I  tactical  data  links.  DoD  policy  designates  Link- 16  as  the  primary  tactical  data  link 
for  all  Service  and  Defense  Agency  C2,  intelligence,  and,  where  practical,  weapon  system 
applications,  unless  an  exception  is  granted.  The  policy  contained  in  DoDD-4630.5  expands  and 
reinforces  the  Assistant  Secretary  of  Defense  (C  I)  Common  Data  Link  (CDL)  policy 
memorandum  of  13  December  1991,  which  stated  that  “unprocessed,  broadband,  imagery  and 
signals  intelligence  data  are  required  to  be  provided  through  CDL  to  intelligence  data 
processing  centers.  All  processed  information  will  be  disseminated  through  Link-16  to  permit 
standardized,  interoperable,  data  link  support  directly  to  the  operator  on  the  battlefield .” 

The  Air  Force  commitment  to  datalinks  has  been  strengthening,  and  current  plans  and  budgets 
reflect  the  intent  to  field  3372  platforms  (aircraft  and  command  nodes)  equipped  with  J-Series 
datalinks  by  2015.  The  installation  rate  funded  by  the  current  (FY00)  budget  (as  indicated  by  the 
Program  Objective  Memorandum  [POM]  submission  and  reported  in  the  Joint  Tactical  Data 
Link  Management  Plan)  is  shown  in  Table  7-5  and  Figure  7-3.  The  challenge  presented  to  this 
study  was  to  suggest  ways  to  accelerate  this  plan  and  to  achieve  the  “linking  of  the  Air  Force”  by 
2005. 


Fiscal  Year 


Figure  7-3.  J-Series  Datalinks  Planned  for  Installation  in  Air  Force  Aircraft 
(per  the  Joint  Tactical  Data  Link  Master  Plan  [JTDLMP]) 


It  was  not  possible  during  the  study  period  to  address  the  engineering  (hardware  and  software) 
issues  across  the  fleet.  The  study  did,  however,  make  it  very  clear  that  a  dedicated  engineer- 
operational  team  should  devote  the  extensive  time  necessary  to  determine  the  proper  hardware 
and  software  concept  of  operations  approach.  This  detailed  analysis  by  the  Air  Force  is  critical 
to  determining  the  proper  approach  to  gaining  digital  message  connectivity  between  combat 
elements.  The  only  viable  alternative  that  we  can  suggest  (and  one  that  is  subject  to  further 
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investigation  and  validation)  is  to  install  SADL  terminals  compatible  with  TADIL-J  in  877  F-16 
Block  40  and  Block  50  aircraft  starting  in  2002  and  to  simultaneously  develop  and  field 
gateways  between  Link- 16  and  SADL.  This  option  could  allow  an  acceleration  of  TADIL-J 
implementation.  When  MIDS  terminals  are  installed  in  these  aircraft,  the  SADL  terminals  can 
be  removed  (and  potentially  returned  to  the  Army). 

If  the  Link-16/SADL  option  is  implemented,  Figure  7-4  illustrates  the  resulting  increase  in  the 
number  of  TADIL-J  equipped  aircraft  from  an  already  accelerated  installation  schedule  (relative 
to  the  schedule  laid  out  in  the  JTDLMP). 
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Figure  7-4.  Datalink  Equipped  Aircraft  Under  Current  and  Alternative  Installation  Schedules 


-•-Total  Datalink  Equipped  Aircraft 

(Link-16  +  SADL  Accelerated  Installation) 
-■-Total  Datalink  Equipped  Aircraft 

(Link-16  +  SADL  under  Baseline  Plan) 

Total  Cost:  $30-50M;  Includes 

Gp-A,  Gp-B,  installation, 

gateway  development,  / 

production,  and  installation 

Assumptions:  Install  SADL  in 
F-16  Blk  40/50  starting  in  2002 
(same  FY  as  MIDS  installs 
begin)  and  complete  field 
mods  in  24  months;  take 
SADL  out  when  MIDS  is 
installed 


00  01  02  03  04  05  06 

Fiscal  Year 
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09 


From  a  longer-term  perspective,  there  are  opportunities  to  rationalize  the  collection  of  Air  Force 
data  links.  One  obstacle  to  changing  out  old  data  links  has  been  the  need  to  maintain 
compatibility  between  existing  platforms  and  their  ground  stations  (or  among  a  collection  of 
platforms)  while  fitting  the  data  links  into  the  space,  weight,  power,  and  frequency  allocation 
limitations  of  existing  systems. 

The  fact  that  installation  of  each  data  link  is  funded  by  the  platform  program  rather  than  by  an 
integrated  data  link  program  office  has  contributed  substantially  to  delays  in  fielding  a  fully 
connected  Air  Force.  One  of  the  conclusions  of  this  study  is  that  the  Air  Force  should  establish  a 
single  manager  for  data  links  and  put  the  budget  for  all  installations  in  the  data  link  program 
rather  than  spreading  it  across  the  multiple  platfonn  programs. 
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Table  7-1 .  Tactical  Data  Links  Managed  by  the  JTDLMP 


Army  Tactical  Data  Link  (ATDL-1) 

Cooperative  Engagement  Capability  (CEC) 

Forward  Area  Air  Defense  (FAAD)  Data  Link  (FDL) 

Ground  Based  Data  Link  (GBDL) 

Interim  JTIDS  Message  Specification  (IJMS) 

Intra  Vehicular  Info  System  (IVIS) 

Link  22 

Marine  Tactical  System  (MTS) 

Patriot  Automated  Digital  Information  Link  (PADIL) 

Tactical  Fire  Direction  System  (TACFIRE) 

Integrated  Broadcast  Service  (IBS)  Note:  Tactical  Information 
Broadcast  Service,  Tactical  Data  Distribution  System,  Tactical 
Reconnaissance  Intelligence  System,  and  Near-Real  Time 
Dissemination  are  planned  for  migration  to  IBS,  and  the  IBS  data  link 
is  planned  to  transition  to  the  J-series  family  of  messages 

TADIL-A  (Link-11) 

TADIL-  B  (Link-1  IB) 

TADIL-C  (Link-4A) 

TADIL-J  (Link-16) 

Variable  Message  Format 

SADL 
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Table  7-2.  CDL  Family  Tactical  Data  Links  Not  Managed  by  the  JTDLMP 


Airborne  Information  Transfer  (ABIT) 

Advanced  Tactical  Airborne  Reconnaissance  System  (ATARS)  Data  Link 

Battle  Group  Passive  Horizon  Extension  System  (BGPHES)  Data  Link 

Common  High-Bandwidth  Data  Link  (CHBDL) 

Guardrail  Interoperable  Data  Link  (IDL) 

Guardrail  Common  Sensor  System  One  (CSS1)  Data  Link 

Guardrail  Common  Sensor  System  Two  (CSS2)  Data  Link 

Guardrail  CSS2  Multi-Role  Data  Link  (MRDL) 

Guardrail  CSS2  Direct  Air  to  Satellite  Relay  (DASR)  Data  Link 

Line  of  Sight  (LOS)  Data  Link  Implementation  (LOS  tether) 

Lightweight  CDL  (LWCDL) 

L-52M  (SR-71 ) 

Rivet  Reach/Rivet  Owl  Data  Link 

Senior  Span 

Senior  Spur 

Senior  Stretch 

Senior  Year  IDL 

Space  CDL 

TR-1  mode  MIST  Airborne  Data  Link 

Table  7-3.  Other  Collection  Data  Links  Not  Managed  by  the  JTDLMP 


Ku-band  Satellite  Communications  (SATCOM)  Data  Link 
Implementation  (UAV) 

Mission  Equipment  Control  Data  link  (MECDL) 

Radar  Data  Transmitting  Set  Data  Link 
Surveillance  and  Control  Data  Link  (SCDL) 

Tactical  UAV  Video 


UHF  SATCOM  Data  Link  Implementation  (UAV) 


Table  7-4.  Other  Non-Collection  Datalinks  Not  Managed  by  the  JTDLMP 


Enhanced  Position  Location  Reporting  System  (EPLRS) 
Position  Location  Reporting  System  (PLRS) 
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7.4  Summary 

For  the  most  part,  the  time-critical  target  solution  does  not  involve  major  technological 
breakthroughs,  but  rather  the  dedication  and  focus  to  concentrate  a  few  resources  and  some 
technical  and  operational  thought  on  the  problem.  Today’s  TCT  systems  rely  heavily  on 
imagery  because  it  is  the  key  source  to  provide  the  necessary  target  recognition  and  identification 
and  geo-registered  coordinates.  Imagery,  especially  wide-area  imagery,  is  not  rapid  in  tasking, 
collection,  processing,  exploitation,  or  dissemination  due  not  only  to  the  very  high  bandwidth 
required  and  the  huge  data  fdes  to  be  searched,  but,  more  important,  the  very  difficult  problem 
involved  in  machine  image  recognition  and  analysis.  The  work  in  image  target  recognition  has 
to  continue,  but  new  advanced  GMTI/SAR  radar  sensors  offer  significant  breakthroughs  in  real¬ 
time  detection,  accurate  location  and  target  feature  information  of  moving  targets  that  can 
provide  the  real-time  cue  needed  to  take  high-resolution  spot  imagery  needed  for  the  targeting 
process. 

The  key  needed  ISR  improvement  is  to  have  continuously  available  and  readily  taskable  ISR 
platforms  that  can  stay  within  rapid  access  of  the  target.  High-altitude,  long-endurance  UAV 
platforms  could  provide  7-day,  24-hour  ISR  coverage,  and  an  advanced  radar  could  provide  all- 
weather,  wide-area  GMTI  coverage  and  moving-target  recognition  as  well  as  simultaneous, 
interleaved  high-resolution  SAR  spot  imagery. 

The  data  link  problem  is  long-standing.  SAB  studies  going  back  to  1991  have  continually 
identified  the  need  for  concentrated  action  to  gain  and  integrate  effective  digital  datalink 
systems.  There  are  solutions  that  capitalize  on  achieving  an  operational  capability  for  transfer  of 
J-series  message  sets  to  attack  aircraft.  The  operational  approach  to  achieving  a  capability 
within  the  deploying  Aerospace  Expeditionary  Forces  in  the  most  rapid,  cost-effective  way 
possible  should  be  followed.  This  will  happen  only  if  a  single  point  of  management  is  achieved. 
Clearly,  the  data  link  solution  consumes  money  and  time,  but  the  tremendous  leverage  this  data 
transfer  capability  provides  makes  the  investment  crucial. 

Linking  the  Air  Force  by  2005  will  require  decisive  action  on  the  part  of  Air  Force  leadership  to 
address  fundamental  human  factors  issues  that  impact  the  perfonnance,  readiness,  and 
sustainability  of  present  systems  for  theater  battle  management.  C2  must  be  elevated  in  status 
and  priority  to  a  level  consistent  with  that  of  other  essential  weapons  systems  and  warfighting 

functions.  The  establishment  of  C2  as  a  weapons  system  has  important  implications  for  Air 

2 

Force  institutions,  organization,  and  processes  used  to  select,  assign,  train,  and  equip  C 
warfighters. 

“Linking  the  Air  Force  by  2005”  is  critical  to  conducting  air  operations  against  time  critical 
targets.  It  is  solvable  if,  and  only  if,  the  Air  Force  staff  drops  institutional  and  political  barriers 
and  addresses  the  TCT  and  associated  data  link  issues  with  an  integrated,  aggressive  approach. 
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Chapter  8 

Technology  and  Architecture  Issues  in  Implementing  the 
Joint  Battlespace  InfoSphere  (JBI) 


8.1  Introduction 

Successive  Air  Force  Scientific  Advisory  Board  (SAB)  studies  have  progressively  defined  the 
JBI  and  recommended  a  program  to  implement  it.40  The  JBI  is  a  powerful  operational  view  of 
information  services  to  the  warfighter.  The  cited  studies  provide  implementation  concepts  that 
are  carefully  grounded  in  modern  information  system  technology  and  practice;  these  concepts 
establish  a  basis  for  moving  forward  to  build  a  JBI  that  will  provide  the  foundation  for 
information-enabled  warfare. 

In  the  course  of  this  study,  a  set  of  lower  level  technical  and  architectural  issues,  as  well  as  some 
exciting  emerging  technological  opportunities,  have  surfaced  from  a  variety  of  sources.  In  a 
sense,  these  involve  a  bottom-up  view,  traversing  layers  of  an  actual  JBI  that  should  be  invisible 
to  application  programmers  and  users,  although  they  entail  some  critical  acquisition  aspects. 
Among  the  questions  the  study  team  has  dealt  with  are: 

1 .  What  is  the  relationship  between  the  JBI  and  the  Defense  Information  Infrastructure  Common 
Operating  Environment  (DII  COE)?  Given  that  the  DII  COE  defines  a  computing  platform  on 
which  programs  that  implement  the  JBI  could,  conceivably,  ride,  what  should  be  the  evolutionary 
path  of  the  DII  COE  itself?41 

2.  What  is  the  right  information  model  (by  implication,  far  more  than  simply  a  data  model)  for  the 
JBI?  What  is  the  “object  schema”  called  for  in  the  earlier  studies,  and  how  is  it  to  be  defined  at  a 
level  of  detail  sufficient  to  allow  an  engineering  team  to  experiment  with  it  or  incorporate  it  in  a 
spiral  JBI  development? 

3.  How  should  the  JBI  cope  with  the  immense  complexity  inherent  in  an  information  model  that 
spans  all  Services,  allies,  warfighting  and  support  communities,  force  echelons,  and  types  of 
operations?  As  a  cautionary  tale,  the  study  team  was  briefed  by  the  Defense  Information  Systems 
Agency  (DISA)  that,  of  the  1 1,000  or  so  data  elements  in  the  current  C2CORE  model ,  partial 
joint  agreement  has  been  reached  on  five  over  the  course  of  years  of  effort,  and  prospects  for 
further  progress  are  limited. 

4.  What  should  the  Air  Force  be  doing  today,  over  the  next  five  years,  and  in  the  longer  term,  to 
establish  the  information  technology  foundation  of  the  JBI  so  that  a  joint,  and  fully  functional 
infosphere  can  be  brought  into  existence  as  soon  as  possible? 

5.  What  are  the  real  lessons  of  the  Internet  and  of  commercial  projects  that  have  succeeded  in 
providing  JBI-like  information  access,  strategic  and  tactical  planning,  execution  management, 
and  assessment  of  functions  to  their  users?  More  importantly,  how  do  these  lessons  translate  to 
the  largely  common,  but  different  in  important  ways,  world  of  command  and  control  (C2),  where 


40  SAB  Report  on  “Information  Management  to  Support  the  Warrior,”  SAB-TR-98-02,  December  1998;  SAB 
Report  on  “Building  the  Joint  Battlespace  InfoSphere,”  SAB-TR-99-02,  December  1999. 

41  An  equally  important  question  may  be  the  relationship  of  the  Department  of  Defense  Global  Information  Grid 

(GIG)  to  the  JBI.  As  currently  defined,  the  GIG  spans  the  entire  hierarchy  of  the  information  infrastructure  that 
supports  future  forces  and  thus  overlaps  significantly  with  the  JBI.  The  lower  layers  of  the  GIG  address  the  kind 
of  connectivity  and  networking  fabric  upon  which  a  JBI  will  depend,  and  the  higher  layers  of  the  GIG  model 
could  merge  with  appropriate  views  of  the  JBI.  However,  this  topic  is  beyond  the  scope  of  the  present 
discussion. 
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requirements  for  security,  reliability,  and  timeliness  may  exceed  those  of  commercial 
applications? 

This  chapter  documents  the  outcome  of  an  extended  discussion  among  members  of  the  study 
team  and  outside  experts  concerned  with  information  technology  (IT)  and  the  JBI.  It  emphasizes 
the  technical  aspects  of  achieving  the  JBI  and  is  intended  to  complement  the  earlier  studies.  It 
also  seeks  to  provide  a  summary  tutorial  on  the  background,  status  and  applications  of  the 
primary  technologies  and  concepts  of  modern  IT  that  bear  on  the  problem.  It  concludes  with  a 
recommended  set  of  actions  to  evolve  the  existing  C  environment  to  the  JBI. 

8.2  Summary  of  the  JBI 

The  following  paragraphs  give  just  enough  information  to  provide  context  for  the  present 
discussion.  The  reader  is  urged  to  consult  the  cited  SAB  reports  for  more  detail.  The  JBI  is  a 
system-of-systems  that  collects,  integrates,  aggregates,  and  distributes  information  to  users  at  all 
echelons.  The  central  premise  is  that  there  be  a  shared  virtual  infonnation  base,  implemented 
through  shared  access  to  information  provided  by  the  many  systems  that  contribute  to  the 
infosphere,  and  with  mechanisms  that  achieve  the  often  described  but  seldom  seen  objective  of 
providing  the  right  infonnation  to  the  right  users  at  the  right  places  and  times.  The  JBI  employs 
four  key  technologies: 

•  Information  exchange  between  individual  users  and  the  JBI  using  a  publish/subscribe  interface  in 
which  users  send  information  known  to  be  relevant  to  the  JBI  and  receive  information  based  on  a 
set  of  user  criteria. 

•  Transformation  of  data  from  multiple  sources  to  a  common  representation  and  of  data  to 
information  to  knowledge  using  elemental  processes  called  fuselets. 

•  Distributed  collaboration  via  shared,  updateable  knowledge  objects. 

•  Templates,  associated  with  assigned  units,  that  describe  operational  capability,  information 
inputs,  and  information  requirements. 

Figure  8-1  is  the  JBI  “logo,”  the  standard  graphical  summary  of  the  JBI’s  functionality.  Around 
the  periphery  are  the  warfighting  processes  that  the  JBI  supports.  Within  the  oval  are  three 
layers  representing  the  broad  categories  of  input,  manipulation,  and  interaction,  with  specific 
examples  if  each.  At  the  core,  the  JBI  employs  a  Structured  Common  Representation  (SCR)  in 
which  one  or  more  object  schemas  are  used  to  define  information.  A  schema  prescribes  a  set  of 
attributes  associated  with  a  given  object  class,  and  a  specific  object  instantiates  the  schema  by 
associating  values  with  these  attributes.  The  schema  thus  employs  metadata  to  define  the 
information  objects  which,  through  publish  and  subscribe  actions,  are  the  lifeblood  of  the  JBI. 
This  lets  the  JBI  be  thought  of  as  an  object  broker  which  automates  the  collection  of  information 
that  has  been  published,  the  distribution  of  objects  in  response  to  queries  or  subscriptions,  and 
the  transformation  of  objects  as  needed  to  support  collaboration  among  users. 
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Figure  8-1.  The  Basic  Structure  and  Primary  Functions  of  the  JBI 


The  full  richness  of  the  JBI  construct  includes  fusion  of  data  streams  to  create  first  information 
and  then  knowledge,  sophisticated  methods  of  human- JBI  interaction,  provisions  for  security  and 
robustness  in  the  face  of  hostile  actions,  and  many  other  dimensions  of  information  support  to 
operational  forces.  The  SCR  will  evolve,  and  its  contents  will  necessarily  be  highly  dynamic, 
growing  and  changing  constantly  as  new  data  sources,  new  user  templates,  and  new  information 
objects  enter  the  JBI.  However,  by  centrally  managing  this  complexity,  the  JBI  makes  life  much 
simpler  for  individual  users  and  platforms  that  employ  its  services. 

As  with  any  complex  information  system,  the  JBI  requires  a  variety  of  views  to  fully  define  its 
structure  and  functions.  For  purposes  of  the  present  discussion,  two  top  level  views  are 
important.42  A  logical  view  describes  the  information  content  of  the  JBI  and  the  information 
processes  that  operate  on  this  content.  As  discussed  in  detail  later,  the  essence  of  this  view  is  an 
information  model,  and  the  SCR,  the  object  schemas,  the  manipulation  processes,  and  the 
information  interfaces  are  critical  elements.  A  physical  view  has  to  do  with  the  way  the  JBI  is 
implemented  in  the  fonn  of  applications  running  on  platforms,  communicating  via  networks,  and 
providing  a  basis  for  dealing  with  the  rapid  evolution  of  computer  and  telecommunications 
technology.  Interfaces  are  still  critical,  but  in  this  view  they  take  the  fonn  of  things  like 
applications  programming  interfaces  (APIs),  messaging  interfaces,  and  network  protocols.  The 
physical  view  involves  both  hardware  and  software  and  defines  the  geographically  distributed 
platform  that  hosts  the  functionality  that  creates  the  logical  view  as  seen  by  users.  A  specific 


42  Additional  important  views  focus  on  security,  human-machine  interfaces,  data  management,  and  other  key 
aspects. 
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example  is  the  fact  that  the  shared  information  base,  which  is  treated  in  the  logical  view  as  a 
single  object  repository,  will  physically  reside  in  a  variety  of  data  stores  associated  with  assorted 
C  nodes,  platforms,  and  systems. 

In  the  discussion  that  follows,  it  is  essential  to  keep  clear  the  distinction  between  the  logical  and 
physical  views  and  to  be  explicit  about  which  of  these  JBI  dimensions  is  involved  in  a  given 
subject.  Our  approach  is  consistent  with  the  Department  of  Defense  (DoD)  Command,  Control, 
Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR) 
Architecture  Framework43  which  defines  operational,  technical,  and  system  views  of  an 
architecture.  The  first  of  these  describes  how  a  given  system  or  system-of-systems  looks  to  an 
operational  user  and  responds  to  that  user’s  needs.  The  second  provides  a  list  of  approved 
standards  for  implementing  the  capability,  and  is  currently  documented  in  the  DoD  Joint 
Technical  Architecture  (JTA).44  The  third  is  the  actual  system  description,  or  “blueprint,”  for 
implementation.  Our  logical  view  is  primarily  an  operational  architecture  perspective,  while  the 
physical  view  is  concerned  with  the  system  architecture,  conditioned  by  a  mandate  to  make 
maximum  use  of  the  JTA. 

Among  other  things,  this  distinction  between  logical  and  physical  views  helps  to  decouple  the 
DII  COE,  which  is  basically  part  of  a  platform/physical  view,  from  the  current  vision  of  the  JBI, 
which  takes  as  its  point  of  departure  a  logical  view  of  information  services  to  warfighters.  Note, 
however,  that  even  these  categories  are  not  perfect,  and  that  a  certain  amount  of  gray  area 
remains  between  them.  For  example,  the  DII  COE  involves  the  application  of  DoD’ s  Shared 
Data  Environment  (SHADE),  which  is  an  approach  to  data  modeling  and  thus  pertains  to  a 
logical  view.  Nonetheless,  framing  the  issues  associated  with  achieving  the  JBI  in  tenns  of 
logical  and  physical  dimensions  is  very  helpful  and  provides  the  basic  structure  for  our  analysis. 

8.3  The  Evolution  of  Information  Technology 

The  IT  on  which  modem  C  relies  is  largely  the  product  of  commercial  development  and 
applications.  However,  the  DoD  strategy  for  achieving  affordable,  interoperable,  supportable 
information  systems  has  diverged  in  several  important  respects  from  the  philosophy  and 
practices  of  the  private  sector.  The  DoD  strategy  is  embodied  in  the  DoD  C4ISR  Architecture 
Framework,  the  JTA,  the  DII  COE,  the  Global  Infonnation  Grid  (GIG),  and  multiple  directives 
dealing  with  requirements,  acquisition,  and  interoperability,  notably  the  Chairman  Joint  Chiefs  of 
Staff  Instruction  62 12.0  IB.  In  seeking  the  best  path  to  exploit  IT  technologies  and  products  for 
information-enabled  warfare,  it  is  useful  to  put  the  current  situation  in  historical  perspective  and 
essential  to  understand  the  differences  between  the  DoD  approach  and  that  of  the  global  IT 
community. 

8.3.1  Trends  in  Commercial  IT  Technology 

Over  the  last  several  decades,  there  has  been  a  pronounced  trend  in  information  technology  for 
the  distinct  realms  of  processing,  storage,  and  networking  to  come  together  within  an 
infrastructure  that  harnesses  multiple  technologies  to  deliver  services  to  users.  Separate  groups 
and  computer  science  disciplines  have  concerned  themselves  with  developing  higher 
performance  computers,  with  evolving  more  efficient  data  bases,  and  with  designing  the  data 


43  DoD  C4 ISR  Architecture  Framework,  Version  2,  18  December  1997. 

44  Department  of  Defense  Joint  Technical  Architecture,  Version  3.1,31  March  2000. 
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communication  networks  that  allow  interconnection  of  these  assets.  Today,  concepts  like 
“network  computing”  and  “net-enabled  data  bases”  highlight  the  fact  that  all  three  aspects  of 
information  infrastructure  must  be  captured  in  a  single,  consistent  framework.  A  critical  step  has 
been  the  emergence  of  the  concept  of  metadata,  about  which  much  more  is  said  later  in  this 
discussion,  because  metadata  allows  the  contents  of  a  data  store  to  be  more  easily  accessed 
through  a  network  transaction.  It  is  the  convergence  of  processors,  data  bases,  and  networks  in  a 
common  process  that  essentially  enables  the  implementation  of  infonnation  infrastructure  as  a 
set  of  infonnation  services.  The  structures  in  which  those  services  are  implemented  are 
hierarchical.  That  means  that  they  subsume  lower  level  mechanisms  and  processes  in  interfaces 
which  conceal  (abstract)  their  detail  from  users  at  higher  levels.  This  fundamental  concept  has 
the  power  to  make  possible  information  sharing  and  common  processes  across  multiple  classes 
of  users  and  diverse  computing  environments. 

8.3.2  The  Difference  in  the  DII  COE45 

The  DII  COE,  the  heart  of  DoD’s  interoperability  strategy,  includes  the  concept  of  shared 
services,  but  focuses  on  detailed  standardization  of  execution  platforms  (computers  running 
specified  operating  systems,  utilities,  shared  libraries,  and  the  like)  to  give  applications  a  fully 
defined  operational  environment.  Indeed,  the  minimum  meaningful  level  of  DII  COE 
compliance  is  the  ability  of  an  application  program  to  coexist  with  others  on  a  platform  without 
causing  conflicts.  The  basic  concept  is  a  set  of  applications,  implementing  C  systems  and 
functions,  riding  on  a  shared  common  infrastructure  that  is  a  point-in-time  instantiation  of  the  list 
of  standards  contained  in  the  JTA.  The  components  of  the  DII  COE  platform  are  largely 
commercial-off-the-shelf  (COTS)  products  that  have  been  segmented  according  to  a  set  of  rules 
so  that  they  can  be  integrated  into  the  core.  The  DII  COE  philosophy  is  based  on  the  idea  that 
interoperability,  sharing  of  applications,  economies  of  scale,  long  term  supportability,  and 
similar  considerations,  demand  a  comprehensive  specification  of  specific  products  and  standards 
that  make  up  this  platform. 

The  infrastructure  then  presents  itself  to  an  application  programmer  in  the  form  of  APIs, 
mechanisms  like  procedure  calls  for  invoking  the  specific  operations  of  specific  versions  of 
specific  embedded  utilities,  and  the  data  model  embodied  in  the  SHADE.  Applications 
programmers  need  to  know  in  detail  the  specific  functions  available  from  the  DII  COE  platform 
version  toward  which  they  are  targeted,  and  subtle  changes  in  those  platform  details,  as  the 
incorporated  commercial  products  evolve,  have  commonly  led  to  problems  in  development, 
integration,  and  compatibility  of  applications  across  multiple  DII  COE  versions. 

The  DII  COE  platform  is  comprised  of  three  shared  environments  as  shown  in  Figure  8-2: 
a  common  operating  environment  (COE),  common  data  environment  (CDE)  and  common 
communications  environment  (CCE).  This  can  be  viewed  as  an  approach  to  the  sort  of  layered 
architecture  concepts  that  have  been  successful  in  many  networking  applications,  as  described  in 
Chapter  3  of  this  Volume.  One  practical  concern  is  the  fact  that  if  it  is  desired  to  extend  the 
DII  COE  platform  by  adding  a  new  shared  component  to  the  core  of  the  environment,  a  complex 
and  time  consuming  process  of  segmenting  it  and  passing  stringent  compatibility  testing  is 


45  A  fuller  discussion  of  the  overall  study  team’s  position  and  recommendations  on  the  DII  COE  is  given  in 

Appendix  4C  to  Chapter  4,  the  Technology  Panel  Report. 

46  Eight  levels  of  compliance  are  defined,  with  the  lowest  dealing  with  documentation  practices;  the  “peaceful 
coexistence”  referred  to  here  is  defined  by  Level  5. 
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entailed.  Another  is  that  backward  compatibility,  defined  as  how  many  DII  COE  releases  into 
the  future  the  APIs  and  common  services  of  an  earlier  version  will  be  supported,  has  been 
limited. 


GCCS 


GCSS 


C2  DOMAIN  APPLICATIONS 


>DII  COE 


Figure  8-2.  The  Basic  Layered  Structure  of  the  Common  Operating  Environment 


The  current  DII  COE  strategy  is  widely  viewed  as  being  on  the  wrong  side  of  what  is  commonly 
called  the  “standards  vs.  standardization”  debate.  This  means  that  the  DII  COE  focuses  on 
standardizing  products  rather  than  on  the  processes  by  which  information  systems  interact. 
Certainly,  it  is  quite  different  from  the  Internet  model,  which  largely  ignores  the  details  of  the 
platforms  involved  in  a  network,  concentrating  instead  on  a  set  of  set  of  protocols  that  ensure 
correct  information  exchange.  However,  the  defects  of  the  DII  COE  should  not  obscure  the 
importance  of  layered  architectures  and  the  utility,  in  some  circumstances,  of  a  pre-defined 
platform  that  promotes  compatibility  of  applications.  We  return  to  this  point  later  in  this  chapter 
in  discussing  the  physical  implementation  of  the  JBI. 

The  Internet  conceives  of  the  shared  infrastructure  as  a  set  of  services  presented  to  a  user  or 
application  through  an  interface  that  hides  (except,  perhaps,  in  a  performance  sense,  such  as 
speed  of  execution)  the  details  of  how  the  service  is  mechanized.  Now,  the  appropriate  standards 
profile  is  the  minimum  set  needed  to  employ  the  available  services.  Examples  would  be  standard 
formats  for  describing  information  (think  of  hypertext  markup  language  [HTML]  to  describe  a 
web  page)  and  standard  protocols  for  using  interaction  services  (think  of  the  Internet  protocol 
stack).  There  can  still  be  the  equivalent  of  a  COE,  CDE  and  CCE.  The  difference  is  in  how  they 
are  invoked  and  how  they  shield  users  from  the  inevitable  turnover  in  the  technologies  and 
products  used  to  implement  them.  We  propose  an  approach  based  on  moving  from  the  idea  of  a 
COE  to  that  of  a  Common  Services  Environment  (CSE),  in  which  the  functions  of  a  COE,  CDE 
and  CCE  are  unified  through  an  abstraction  interface. 
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This  approach  is  consistent  with  the  idea  of  decoupling  the  logical  and  physical  views. 

Something  akin  to  the  DII  COE,  ideally  with  better  provisions  for  technology  refreshment  and 
backward  compatibility,  would  continue  to  establish  standards  and  guidelines  for  the  physical 
layers  of  the  JBI.  Similarly,  the  CSE  that  is  the  essence  of  the  logical  view  must  be  fully  defined 
in  terms  of  rules,  constraints,  procedures,  guidelines  and  policies,  including  selective  use  of 
standards  for  such  things  as  publish  and  subscribe  services.  The  goal  is  to  allow  the  physical  and 
logical  environments  to  respond  to  each  other’s  evolution  while  remaining  separated  in  such  a 
way  that  changes  in  the  implementation  of  one  do  not  force  changes  in  the  other.  For  example, 
as  the  CSE  grows  and  demands  more  computational  and  communications  power,  it  may  generate 
requirements  for  upgrades  to  the  physical  environment.  Once  again,  the  Internet  provides 
powerful  evidence  that  a  set  of  services  and  their  associated  interfaces  can  be  maintained  across 
many  generations  of  change  in  the  physical  platforms  on  which  they  ride. 

8.4  Information  Services  for  the  JBI 

The  first  priority  concerns  the  logical  view  of  the  JBI,  the  way  in  which  an  efficient  infonnation 
model  is  employed  to  provide  information  services.  For  purposes  of  the  present  discussion,  an 
information  model  is  defined  as: 

A  schema  for  the  representation  of  data,  together  with  the  processes  which  (a)  aggregate 
and  associate  data  to  create  information,  (b)  fuse  and  interpret  data  to  create  knowledge, 
and  (c)  import,  transform,  access,  and  export  data,  information  and  knowledge  to  meet 
user  needs. 

Then  the  CSE  presents  the  JBI  to  a  user  as  one  or  more  information  service  interfaces,  defined  in 
terms  which  are  transparent  to  the  technology  used  to  implement  the  underlying  platform  and 
intuitively  natural  for  applications  programmers  to  use.  Since  the  essence  of  the  JBI  concept  is 
to  allow  individual  users,  platforms,  and  systems  to  meet  their  infonnation  needs  via  a  publish 
and  subscribe  interface  to  a  shared  Infosphere,  the  top  level  services  are  simply  those  described 
in  the  manipulation  layer  of  Figure  8-1 : 

•  Publish.  The  InfoSphere  receives  and  processes  data  or  information  transmitted  by  a  platform, 
system  or  user  upon  the  occurrence  of  an  event  which  meets  the  criteria  for  the  action 

•  Subscribe/Query.  A  user,  platform  or  system  obtains  information  presented  by  the  InfoSphere 
when  the  criteria  of  a  subscription  or  query  are  met.  A  subscription  is  defined  by  a  standing  set  of 
criteria;  a  query  is  generated  by  an  ad  hoc  information  need. 

•  Transform.  The  InfoSphere  activates  fuselets  that  perform  the  necessary  operations  to  produce 
required  information  objects  and  representations 

•  Control.  The  InfoSphere  monitors  and  controls  JBI  functions 

8.4.1  Information  Models 

8.4. 1.1  Information  in  the  JBI 

The  JBI  is  predicated  on  the  exchange  of  messages,  for  example,  documents,  reports,  or 
commands,  within  a  force.  The  basic  publish/subscribe  mechanisms  must  deal  with  infonnation 
integrity,  security,  quality  (including  timeliness  and  level  of  trust),  evolution  of  missions  and 
technologies,  and  access  controls  or  user  privileges.  The  infonnation  model  on  which  these 
transactions  are  based  must  capture  the  ways  diverse  data  are  imported  (including  from  legacy 
systems),  represented,  managed,  and  exported.  Cunent  data  modeling  approaches  cannot  meet 
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the  JBI  need,  but  furnish  a  useful  starting  point  in  identifying  the  types  of  data  involved  and  their 
owners  and  users. 

In  reality,  while  it  is  convenient  to  speak  of  “the”  JBI  infonnation  model,  there  will  never  be  a 
final,  definitive  model  because  the  information  basis  of  warfare  is  constantly  changing. 
Additionally,  the  very  complexity  of  the  JBI  information  content  is  likely  to  demand  a  number  of 
models,  each  with  its  own  set  of  meanings  (ontology)  and  a  set  of  callable  service  interfaces  that 
are  matched  to  the  needs  of  various  user  communities.  What’s  needed,  therefore,  is  a  framework 
and  process  for  the  orderly  evolution  of  one  or  more  information  models,  based  on  the  concepts 
that  have  made  the  Internet  so  successful  and  on  the  most  promising  technologies  for  defining 
and  implementing  the  object  schemas  and  associated  processes.  Elements  of  that  framework 
include  structure,  metadata,  and  access  methods  for  the  JBI  information  base.  For  example, 
standards  for  metadata  definition  may  be  useful  in  preserving  compatibility  of  information 
objects  across  generations  of  the  information  systems  which  use  them.  It  is  critical  that  the 
information  model  allow  users  to  tailor  infonnation  access  to  their  specific  needs,  for  example, 
by  presenting  information  in  fonnats  that  are  native  to  their  legacy  systems  and  to  their  tactics, 
techniques  and  procedures. 

Shared,  Distributed  Tailored  Operational 

Information  Base  Pictures 


f 


Communities  of  Interest 


Figure  8-3  The  JBI  Shared  Information  Repository  Deals  with  Many  Warfighting  and  Support 
Communities  and  Supports  Tailored  Information  Products  at  All  Force  Echelons 


Figure  8-3  illustrates  several  aspects  of  the  problem.  The  shared  information  repository  is  shown 
as  segmented  both  by  the  various  communities  of  interest  that  contribute  to  and  use  the  JBI,  for 
example,  air,  land,  maritime,  and  support  organizations,  and  by  the  organizational  hierarchy, 
from  overall  command  down  to  individual  warfighters.  Implicit  in  the  JBI  is  the  ability  to  drill 
down  when  additional  detail  is  needed  and  to  aggregate  data  to  synthesize  higher  level  views  and 
decision  aids.  The  information  base  then  supports  the  generation  of  a  Family  of  Integrated 


Operational  Pictures  (FIOP),  7  with  tailored  operational  views  for  individual  users;  a  simple 
example  is  indicated. 

Figure  8-3  also  highlights  why  it  will  be  important  to  the  success  of  the  JBI  to  carefully  define 
the  roles  of  the  individuals  and  organizations  who  interact  with  the  shared  information  base  and 
to  make  them  accountable  for  fulfilling  those  roles.  In  terms  of  the  content  of  the  shared 
repository,  the  basic  roles  are  owner  and  user.  Various  areas  of  content  in  the  shared  repository 
will  be  owned  by  specific  communities  of  interest  and  by  organizations  within  those 
communities.  Ownership  is  implicit  in  the  publication  of  data  and  infonnation  into  the 
InfoSphere,  whether  in  the  form  of  updates  to  data  bases  or  in  the  form  of  reports,  commands,  or 
other  messages.  Similarly,  a  platform,  system,  or  individual  who  accesses  the  InfoSphere  via 
subscribe  or  query  actions  has  an  implicitly  defined  user  role.  The  ownership  role  is  especially 
important  because  the  integrity  and  utility  of  the  JBI  will,  in  the  final  analysis,  depend  on  the 
ability  and  effort  of  data  owners  to  ensure  the  publication  of  information  with  the  quality  needed 
by  the  warfighters  that  the  JBI  supports. 

Another  aspect  this  view  of  infonnation  services  is  the  expectation  that  users  can  and  will  define 
their  “business  processes”  in  such  a  way  that  the  flow  of  information,  the  nature  of  required 
services,  and  priorities  for  information  support  can  be  articulated  and  accounted  for  in  the  JBI. 

In  the  commercial  world,  where  much  of  the  technology  and  many  of  the  concepts  that  support 
the  JBI  have  emerged,  it  is  widely  understood  that  an  enterprise  architecture  must  start  with  the 
understanding  and  modeling  of  business  practices  and  then  of  the  processes  that  underlie  them. 
From  this,  the  supporting  information  model  can  be  derived.  While  a  business  model  may  seem 
foreign  to  military  C  ,  there  are  many  parallels;  an  example  would  be  planning  at  the  strategic, 
operational  and  tactical  levels.  In  fact,  this  is  essentially  what  is  meant  by  an  operational 
architecture,  and  the  increased  emphasis  now  being  placed  by  the  Joint  Staff  and  others  on 
defining  a  Joint  Operational  Architecture,  supported  by  a  set  of  Joint  Mission  Architectures,  is  an 
important  step  in  laying  the  foundation  for  a  JBI.  Adopting  such  a  “business”  point  of  view  will 
be  essential  to  taking  advantage  of  the  new  information  system  paradigm. 

8.4. 1.2  Current  Data  Models 

A  huge  amount  of  effort  has  been  expended  over  many  years  in  building  a  variety  of  existing 
data  models.  The  Core  Architecture  Data  Model  (CADM)  of  the  C4ISR  Architecture  Framework 
is  a  compendium  of  data  elements  intended  to  provide  the  basis  for  defining  Information 
Exchange  Requirements  in  the  course  of  constructing  the  Operational  View  of  an  architecture. 
The  Defense  Data  Dictionary  System  (DDDS)  is  intended  to  be  the  repository  for  data  element 
definitions  across  DoD.  CADM  is  for  building  a  database  to  collect  architecture  info,  some  of 
which  would  be  the  data  models  for  particular  systems.  DDDS,  on  the  other  hand,  is  the 
collection  of  standard  data  elements  from  which  developers  are  expected  to  choose  when 
building  data  models  that  are  later  captured  in  a  CADM-based  database. 

At  the  C  level,  the  most  common  model  seems  to  be  C"CORE,  which  is  largely  an  Army  data 
model,  although  the  Army  also  has  its  Army  Integrated  Core  Data  Model  and  the  Land  C2 
Information  Exchange  Model.  The  latter  is  also  the  North  Atlantic  Treaty  Organization  (NATO) 


47  FIOP  is  the  current  preferred  term  for  what  was  formerly  labeled  the  Common  Operating  Picture  and  is  intended 
to  lead  eventually  to  a  single  Common  Relevant  Operational  Picture.  For  information,  contact  Director, 
Interoperability,  OUSD(AT&L). 
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reference  model  known  as  ADaTP-32  and  is  due  to  become  a  NATO  STANAG.  Message 
structures  like  the  Link- 16  J-series  messages  and  the  US  Message  Transmission  Format  could 
also  be  seen  as  elements  of  a  data  model.  At  the  bottom  of  the  modeling  pyramid,  every 
information  system  and  network  has  its  own  data  model;  an  example  is  the  data  base  design  of 
the  Air  Operations  Data  Base  defined  for  the  Theater  Battle  Management  Core  Systems 
(TBMCS). 

In  general,  the  prevailing  philosophy  of  data  modelers  in  the  defense  community  has  been  to 
pursue  comprehensive  data  element  definitions  that  meet  the  needs  of  all  warfighters.  There  are 
two  basic  reasons  why  these  approaches  have  been  unsuccessful: 

•  Like  any  data  dictionary,  the  resulting  models  tend  to  be  flat,  that  is,  have  no  hierarchy  or  other 
structure,  which  avoids  issues  of  precedence  but  makes  them  extremely  cumbersome  to  use 

•  They  make  no  provision  for  tailoring  by  user  communities,  and  thus  bring  on  the  endless  debates 
about  details  that  have,  in  fact,  bedeviled  DoD  data  modelers 

The  CADM  is  drawn  up  as  an  entity-relationship  diagram.  There  is  generally  no  way  in  such 
models  to  declare  domains  or  to  segment  the  contents  to  simplify  the  task  of  using  the  content  in 
a  particular  warfighting  context.  These  models  are  so  huge,  so  complex,  and  so  difficult  to  keep 
current  with  evolving  systems  and  operational  needs  that  they  are  destined  to  fail.  On  the  other 
hand,  hierarchy  alone  is  not  sufficient  to  deal  with  this  level  of  complexity.  The  X.500  directory 
services  standard  defines  a  sophisticated  hierarchy  scheme  which  has  proved,  in  practice,  hard  to 
manage  and  has  thus  far  failed  to  solve  the  problem  of  efficiently  addressing  large  numbers  of 
network  subscribers.  This  sad  history  suggests  that  the  problem  of  dealing  with  the  size  and 
diversity  of  the  JBI  information  base,  even  as  an  aggregation  of  infonnation  from  multiple 
sources,  may  prove  to  be  the  principal  obstacle  to  achieving  its  promise. 

8.4. 1.3  From  Format  to  Meaning 

A  number  of  technology  options  have  emerged  that  may  help  in  dealing  with  this  problem. 
Methods  for  describing,  manipulating  and  presenting  data  that  were  not  available  in  earlier 
generations  are  critical  to  dealing  with  the  tidal  wave  of  data  inundating  modern  C  systems. 

Five  essential  elements  or  concepts  are  fonnat  standards,  markup  languages,  metadata, 
middleware,  and  abstraction. 

Format  Standards  and  Markup  Languages.  A  set  of  format  standards  (GIF  and  JPEG  for 
graphics,  RTF  and  TXT  for  text,  etc.)  have  emerged  by  consensus  in  association  with  popular 
desktop  applications.  These  allow  different  applications  (for  example,  word  processors)  to  share 
files  and  thus  promote  openness  and  innovation  because  new  and  better  software  can  be  adopted 
without  losing  legacy  data  or  sacrificing  interoperability  with  users  of  other  software.  This 
notion  goes  an  important  step  further  with  markup  languages  which  provide  a  powerful  and 
standard  way  to  describe  a  data  object.  The  best  known  of  these  HTML,  which  essentially 
allows  the  format  (fonts,  graphics,  etc.)  that  comprise  a  web  page  to  be  described.  Then,  in 
principle,  any  web  browser  can  access  the  page,  and  users  can  freely  choose  the  browser  or 
browsers  whose  features  best  meet  their  needs.  HTML  even  enables  a  class  of  utility  programs 
for  designing  and  implementing  web  pages,  eliminating  the  need  to  master  the  language  itself. 

In  practice,  however,  variants  of  HTML  have  been  promulgated  by  different  vendors  that  make  it 
possible  to  build  pages  that  don’t  work  in  all  browsers.  This  is  an  example  of  an  area  where  a 
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widely  supported  standard  would  be  a  good  thing,  delivering  more  in  the  form  of  interoperability 
than  it  costs  in  the  form  of  limits  on  innovation. 


Metadata.  HTML  describes  an  information  object  (a  web  page)  in  tenns  of format.  The  next 
logical  step  is  to  enable  the  interface  to  an  object  to  describe  the  content  of  that  object.  The  idea 
of  describing  content  in  some  standard,  widely  understood  way,  formalized  by  a  language,  is 
generalized  in  the  concept  known  as  metadata.  Trivially  defined  as  “data  about  data,”  metadata 
has,  in  fact,  multiple  meanings  in  different  contexts.  In  this  discussion,  it  is  used  in  the  sense  of 
a  prescribed  way  to  define  a  set  of  attributes  of  a  data  object  that  allow  an  infonnation  process  to 
efficiently  access  and  act  upon  that  object. 

The  best  known  example  of  a  metadata  implementation  is  the  extensible  Markup  Language 
(XML)  which  allows  the  definition  of  “tags”  that  prescribe  the  format  of  a  set  of  attributes  that 
have  been  defined  for  the  elements  of  a  data  store.  These  tags  are  conventionally  stored  in 
repositories  that  can  be  accessed  by  processes  seeking  to  interact  with  the  data  they  describe. 
Furthermore,  XML  facilitates  segmentation  of  a  data  store  into  domains  that  are  of  interest  to 
specific  user  communities  by  allowing  “namespaces”  to  be  established  and  assigned  to  individual 
managers  for  maintenance  and  updating.  Namespaces  allow  common  XML  tags  to  be  reused  in 
various  contexts  while  retaining  unique  identities.  Another  important  ingredient  is  the  use  of 
Document  Type  Definitions  (DTDs)  that  define  how  the  author  of  the  XML  tags  for  a  document 
intended  them  to  be  interpreted. 

In  a  C  context,  the  operational  domains  that  are  managed  by  namespaces  might  be  things  like  air 
operations,  meteorology,  and  intelligence.  Clearly,  there  will  be  many  data  items  and 
information  objects  that  are  used  in  multiple  domains,  and  careful  design  of  both  the  infonnation 
base  itself  and  the  XML  tags  for  such  common  content  will  be  very  important.  DoD,  through 
DISA,  has  established  a  DII  COE  XML  Registry  for  tags,  data  structures,  and  DTDs,  and  has 
assigned  Designated  Managers  for  a  variety  of  namespaces;  for  example,  the  Air  Force  CDE 
staff  is  responsible  for  the  Aerospace  Operations  namespace.  It  would  be  logical  to  define 
namespaces  for  domains  within  the  JBI,  and  useful  to  maintain  mappings  from  these  to  other 
metadata  repositories  such  as  the  DII  COE  XML  Registry. 

Taking  a  track  as  an  example  of  a  data  object  in  a  C  system,  the  metadata  tag  might  define 
attributes  such  as  the  category  of  the  target,  the  coordinates  of  the  state  vector  defining  the 
target’s  position  and  movement,  the  geographical  region  in  which  it  is  located,  and  timeliness  of 
the  most  recent  validated  sensor  report.  A  user  interested  in,  say,  the  mobile  surface  to  air 
missile  batteries  detected  in  a  specified  region  in  the  last  24  hours  could  use  the  XML  tags  to 
rapidly  find  and  access  the  details  of  the  relevant  tracks.  A  data  store  that  is  “XML-enabled”  by 
defining  namespaces,  defining  attributes,  and  writing  tags  is  a  long  way  along  the  path  toward 
being  usable  in  the  JBI.  With  such  an  interface,  the  content  of  a  data  store  is  machine-readable, 
and  XML  thus  allows  the  implementation  of  syn  tactic  interfaces  to  data,  with  attributes  of  the 
data  presented  to  an  external  process  or  user  as  the  basis  for  interoperability  and  efficient  access. 

This  is  the  fundamental  idea  behind  an  XML  “wrapper”  around  an  existing  data  store  that  allows 
it  to  become  part  of  a  larger  repository.  These  wrappers  are  defined  by  DTDs,  but  in  an 
application  like  the  JBI,  the  DTD  content  will  need  to  go  beyond  a  simple  mapping  of  the 
various  fields  in  the  tags  that  describe  the  data.  The  DTD  should  also  deal  with  the  quality  of  the 
data  in  terms  of  such  attributes  as  timeliness,  ownership  and  the  “pedigree”  of  the  data  that 
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establishes,  among  other  thing,  the  level  of  trust  accorded  to  the  data’s  source.  Approaching 
metadata  in  this  way  puts  the  JBI  squarely  in  the  IT  mainstream  and  ensures  that  its  data  model 
will  be  widely  understood  and  easy  for  application  developers  to  use. 

Segmenting  the  shared  information  base  into  domains  will  never  be  precise,  because  certain 
objects  will  always  be  of  interest  in  multiple  domains.  For  example,  consider  cruise  missile 
tracks.  Every  warfighting  community  involved  in  an  operational  theater  is  likely  to  subscribe  to 
current  information  on  detected  inbound  cruise  missiles.  The  JBI  infonnation  model  must  ensure 
that  the  various  domains  are  updated  consistently  and  in  real  time,  even  at  the  expense  of  some 
duplication  of  data.  This  might  be  implemented  as  a  replication  function  in  which  a  central 
cruise  missile  track  domain  publishes  updates  to  appropriate  subscribing  domains,  so  that  the 
central  track  file  ensures  consistency  and  eliminates  the  propagation  of  false  or  uncorrelated 
tracks. 

Middleware  and  Abstraction.  Middleware  is  used  in  this  discussion  in  a  very  general  sense  to 
designate  a  broad  class  of  software  that  mediates  between  one  or  more  classes  of  users  and  a  set 
of  information  services.  Middleware  can  do  anything  from  establishing  an  intranet  for  passing 
e-mail  and  scheduling  meetings  to  mechanizing  the  processes  associated  with  accessing  data  and 
scheduling  the  delivery  of  products.  A  fundamental  task  of  JBI  middleware  will  be  to  ensure 
synchronization  and  consistency  of  content  across  domains  and  to  resolve  conflicts  such  as 
inconsistent  reports  about  an  object;  if  necessary,  such  situations  may  require  alerting  a  human 
operator. 

Using  tools  like  metadata  and  middleware,  an  information  infrastructure  can  implement  one  or 
more  layers  of  abstraction.  This  is  much  like  what  the  developers  of  structured  programming 
called  “information  hiding,”  and  the  idea  is  that  those  details  of  a  process  that  an  external  user 
does  not  need  to  know  in  order  to  use  the  process  should  not  be  exposed.  In  defining 
information  services,  abstraction  layers  allow  a  user  (which  might  be  a  human  operator,  an 
application  program,  another  data  store,  or  something  else)  to  invoke  the  service  in  terms  that  are 
natural  and  easy  to  use.  A  user  who  has  detected  a  hostile  target  might  publish  the  event  in  terms 
of  “an  object  of  class  <SA-20>  has  been  detected  at  coordinates  <x,  y,  z,  t>.”  Then  the  JBI 
would  send  the  track  update  to  every  user  who  had  subscribed  to  this  class  of  target  and  whose 
area  of  interest  overlaps  a  circle  of  radius  n  kilometers,  where  n  is  the  engagement  range  of  the 
threat  system. 

The  power  and  utility  of  middleware  will  be  greatly  extended  by  the  use  of  agent  technology. 
Agents  are  a  complex  topic  and  the  subject  of  a  great  amount  of  current  research,  but  the  basic 
idea  is  that  of  software  entities  that  contain  enough  intelligence  to  autonomously  perfonn 
functions  on  behalf  of  a  user,  often  with  incomplete  specification  of  the  task.  Agents  do  things 
like  traverse  data  stores  looking  for  content  of  interest,  not  just  on  the  basis  of  a  list  of 
parameters  but  of  “understanding”  of  the  true  information  needs  of  the  user  (which  might  be  an 
application  program)  for  which  they  are  acting. 

Future  Trends.  Syntactic  interfaces  using  XML  represent  the  current  state  of  the  art.  They  are 
the  basis  for  an  ongoing  revolution  in  electronic  commerce  (“business-to-business”),  process 
reengineering,  and  what  have  come  to  be  known  as  “enterprise  architectures.”  XML,  or  an 
equivalent  standard,  allows  the  construction  of  the  attribute/value  pairs  of  an  object  schema 
under  the  JBI.  However,  the  next  step  in  the  evolution  of  infonnation  models  is  beginning  to 
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take  shape.  A  markup  language  that  makes  the  content  of  a  data  store  machine-understandable, 
that  is,  that  presents  not  only  the  attributes  but  the  meaning  of  the  information,  creates  a  semantic 
interface.  This  allows  the  definition  of  an  ontology,  a  shared  basis  of  meaning  about  the  content 
of  an  information  store,  and  is  an  obvious  step  in  the  direction  of  fully  natural  interfaces  in  which 
a  user  has  no  need  to  know  the  arcane  details  of  computer  languages,  data  structures,  and  syntax. 
The  needs  of  electronic  commerce  can  be  expected  to  drive  rapid  progress  in  this  area. 

Such  an  interface,  using  middleware  based  on  agent  technology,  is  being  explored  by  the 
Defense  Advanced  Research  Projects  Agency  (DARPA).  The  associated  language  is  the 
DARPA  Agent  Markup  Language  (DAML),  and  the  goal  is  to  enable  agents  that  not  only 
identify  but  understand  data  objects  and  thus  allow  great  improvement  in  the  quality  and 
productivity  of  information  services  that  depend  on  accessing  data.  Now,  for  example,  a  query 
to  the  data  store  could  use  one  or  more  agents  that  contain  the  intelligence  to  reject  data  objects 
whose  content  is  not  consistent  with  the  needs  of  a  decision  aiding  tool  that  initiated  the  query. 

In  the  language  of  the  JBI,  agent  technology  may  prove  to  be  a  powerful  way  to  implement 
fuselets.  The  full  potential  of  this  concept  is  only  beginning  to  appear.  Existing  technologies 
such  as  XML  provide  a  solid  basis  for  the  initial  implementation  of  the  JBI,  but  as  the  generation 
of  technology  represented  by  DAML  matures  and  is  instantiated  in  tools  and  products,  the  full 
functionality  and  power  of  the  JBI  information  model,  and  the  services  it  empowers,  will  become 
available. 

8.4.2  The  JBI  Information  Model 

With  the  above  as  background,  we  can  discuss  the  characteristics  that  the  JBI  information  model 
should  possess.  The  ultimate  objective  is  to  present  a  set  of  information  services  to  users  and 
applications  that  are  robust,  policy-compliant,  easy  to  use,  interoperable  across  communities  and 
systems,  and  transparently  evolvable  with  the  progress  of  implementing  technology.  Key 
attributes  are  as  follows: 

8. 4. 2.1  Domains 

Information  stores  and  associated  processes  must  allow  segmentation  into  domains  to  make 
manageable  the  complexity  of  the  data  employed  by  individual  communities  and  systems. 
Domains  also  support  the  need  for  individual  user  communities  to  collect  and  structure  data  to 
meet  their  specific  needs  and  to  exercise  data  ownership.  Information  sharing  across  domain 
boundaries  must  be  easy  to  achieve  (for  example,  a  submarine  may  find  itself  controlling  a 
unmanned  aerial  vehicle).  As  noted  earlier,  XML  namespaces  and  DTDs  offer  an  initial 
approach  to  achieving  this.  Note  that  the  two  goals  specified  here  are  oppositional — segmenting 
information  into  domains  makes  it  harder  to  share  across  domains.  Moreover,  there  will  never 
be  a  clean  way  to  segment  data  into  domains  because  no  two  user  communities  will  have  the 
same  way  of  parsing  data.  There  must  therefore  be  accompanying  middleware  for 
synchronization  of  shared  infonnation  and  resolution  of  discrepancies.  It  may  prove  useful  for 
widely  shared  data  and  information  objects  to  create  centralized  data  bases  which  are  part  of  the 
JBI  information  model,  are  not  user-defined,  and  are  used  to  replicate  consistent  updates  into 
various  domains. 
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8. 4. 2. 2  Structure 

Data  is  inherently  hierarchical.  Objects  such  as  messages  and  platforms  derive  from  higher  order 
objects  (say,  message  catalogues  and  military  fonnations)  and  imply  lower  order  objects  (say, 
fields  and  subsystems).  Whether  or  not  strict  object  orientation,  involving  inheritance, 
polymorphism,  encapsulation,  etc.,  is  employed  (previous  SAB  JBI  reports  say  it  need  not  be),  a 
hierarchical  data  structure  is  enormously  more  efficient  than  a  flat  one  when  a  search  is  being 
performed  with  less-than-complete  specification  of  the  information  sought.  Other  kinds  of 
structure  are  also  useful.  HTML  documents  use  hyperlinks  to  associate  content  on  various 
pages.  Semantic  interfaces  offer  additional  possibilities.  The  point  is  that  the  huge,  diverse 
content  of  the  JBI  shared  information  repository  must  be  embodied  in  a  structured  representation 
if  it  is  to  be  used  with  high  integrity  and  in  real  or  near-real  time. 

An  important,  unsolved  technical  issue  is  involved  here.  The  JBI  construct  implies  that  the 
system  can  associate  a  unique  identifier  with  an  information  object  and  then  be  able  to  find  out 
such  properties  as  the  object’s  location,  type,  and  access  control  pennissions.  Despite  the  efforts 
of  bodies  such  as  the  Internet  Engineering  Task  Force  (IETF)  and  World  Wide  Web  Consortium 
(W3C),  no  such  infonnation  identification  method  has  yet  been  agreed  upon,  implemented  and 
deployed.  One  system  with  the  desired  properties  is  the  “Handle  System”  developed  by  CNRI 
under  DARPA  sponsorship  which  has  its  roots  in  the  digital  library  community.  The  JBI  must 
have  such  a  capability,  and  the  responsible  developing  organizations  will  need  to  work  with  the 
IT  community  and,  eventually,  choose  and  implement  a  suitable  method. 

8.4.23  Compatibility  with  Heterogeneous,  Legacy,  and  Local  Data  Stores 

For  practical  reasons,  it  is  unlikely  to  be  feasible  that  the  vast  array  of  legacy  data  bases  be 
translated  into  an  entirely  new  JBI  object  schema,  certainly  not  all  at  once.  The  information 
model  must  provide  for  wrappers,  translators  (presumably  using  fuselets),  or  other  mechanisms 
that  allow  incorporation  of  such  data  stores  and  seamless  access  to  them  through  the  interfaces  of 
the  infonnation  services  set.  Similarly,  there  will  be  circumstances  where  specialized  or 
privileged  data  must  be  accommodated  in  local  stores.  As  a  general  attribute,  the  JBI 
information  model  must  provide  the  facilities  that  allow  heterogeneous  data  stores  to  be 
integrated  under  common  abstraction  layers  and  their  associated  interfaces.  Together  with 
segmentation,  this  attribute  addresses  data  ownership  and  deals  with  the  operational  reality  that 
various  segments  of  the  aggregated  data  environment  will  be  owned  and  managed  by  various 
authorities,  each  of  whom  will  require  appropriate  controls  over  content  and  not  all  of  whom  will 
agree  on  all  tenns. 
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Figure  8-4.  Structure  and  Features  of  a  Notional  JBI  Shared  Information  Base ,  Drawn  to  Emphasize  the 

Logical  View  of  the  InfoSphere 


Figure  8-4  suggests  the  nature  of  a  JBI  shared  database  that  embodies  these  principles.  This  is 
very  much  a  logical  view;  the  physical  instantiation  will  involve  a  networked  ensemble  of  nodes 
and  a  highly  distributed  information  processing  and  storage  structure.  At  the  top  of  the  logical 
structure,  users  see  the  JBI  through  a  set  of  infonnation  services  interfaces  for  publish,  subscribe, 
and  query.  At  the  bottom,  the  owners  of  various  information  sets  are  responsible  for  updating 
the  content  of  their  respective  domains.  Legacy  and  new  databases  are  XML-tagged;  for  the 
former,  this  provides  the  necessary  wrapper  to  allow  incorporation  into  the  JBI.  Middleware  is 
responsible  for  maintaining  consistency  across  domains;  for  transfonning  data  to  a  common 
SCR;  for  aggregation,  fusion  and  processing  to  yield  information  and  knowledge;  and  for 
supporting  the  user  interface.  As  noted  earlier,  a  set  of  central  data  bases  for  data  and 
information  that  is  widely  shared  across  domains  may  be  useful.  Again,  “middleware”  is  used 
here  in  a  very  general  sense  to  refer  to  the  many  processes  that  act  on  data  and  information  from 
multiple  sources  and  users  to  knit  together  JBI  functions  and  services  across  a  heterogeneous  and 
distributed  physical  implementation. 

8. 4. 2.4  Abstraction 

The  information  model  must  present  the  information  base  through  one  or  more  abstraction  layers 
that  hide  the  implementation  details.  Initially,  these  will  be  syntactic  interfaces,  but  semantic 
interfaces  should  be  implemented  as  the  technology  matures.  Another  dimension  of  abstraction 
is  the  capability  of  the  JBI  information  model  to  aggregate  data  to  create  information  and  to  fuse 
and  process  information  to  create  knowledge.  Within  the  hierarchy  of  the  information  model, 
middleware,  especially  using  agents,  can  construct  information  and  knowledge  objects  that  are 
presented  to  users  at  the  appropriate  service  interfaces. 
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8. 4. 2. 5  Management 

The  JBI  will  become  perhaps  the  most  critical  resource  commanders  and  warfighters  have 
available  in  conducting  operations.  It  will  sit  at  the  focus  of  doctrine,  operational  priorities,  and 
national  policy  governing  the  use  of  military  force.  Its  perfonnance  and  integrity  will  largely 
determine  success  or  failure.  At  the  same  time,  it  will  be  one  of  the  most  complex  information 
systems  ever  built.  For  all  these  reasons,  a  critical  attribute  is  the  structure  that  is  put  in  place  to 
manage  the  JBI,  both  in  terms  of  its  real-time  operations  and  in  terms  of  its  development, 
evolution,  certification  and  integration  with  supported  forces.  The  related  issue  of  centralized  vs. 
distributed  control  is  discussed  in  more  detail  later. 

As  shown  in  Figure  8-1,  control  is  a  basic  JBI  service  or  function.  Perhaps  a  better  term,  since 
the  JBI  will  incorporate  many  systems  and  information  sources,  might  be  “governance.”  JBI 
operations  will  be  largely  dictated  by  policies  established  at  various  levels  of  command; 
particularly  at  the  operational  and  tactical  levels,  the  JBI  must  allow  commanders  to  adjust  their 
policies  as  the  exigencies  of  an  operation  dictate.  Highly  skilled  system  administrators, 
communication  and  networking  specialists,  and  other  dedicated  personnel  will  be  required  to 
monitor  and  control  infosphere  operations  and  to  diagnose  and  correct  problems.  As  the 
InfoSphere  system-of-systems  evolves,  continued  verification  and  validation  of  its  hardware  and 
software,  including  accreditation  to  handle  classified  information,  will  be  a  continuing  challenge. 
Diverse,  and  often  conflicting,  requirements  from  various  user  communities  must  be  harmonized 
and  a  coherent  program  implemented  to  keep  the  JBI  current  and  supportable.  Integration  with 
legacy  systems,  many  of  which  will  present  proprietary  and  incompletely  documented  interfaces, 
will  be  yet  another  ongoing  challenge. 

The  JBI  transfers  complexity  from  individual  platforms  and  systems  to  a  shared  information 
infrastructure.  This  has  great  potential  to  enhance  force  effectiveness  and  to  reduce  the  burden 
on  individual  users.  However,  the  price  to  be  paid  is  a  very  large  and  complex  management  task. 
Within  the  InfoSphere,  there  will  be  functional  domains,  each  with  its  associated  control  and 
management  processes.  The  challenge  of  dealing  with  the  federated,  system-of-systems  nature 
of  the  JBI  while  ensuring  consistent  and  robust  information  services  to  all  users  must  be  treated 
as  a  central  concern  in  bringing  the  JBI  to  reality. 

8. 4. 2. 6  Security 

The  JBI  interacts  with  many  users  and  systems,  integrates  the  full  panoply  of  operational  and 
intelligence  information,  and  supports  the  most  critical  warfighting  decisions.  The  security  and 
integrity  of  its  information  are  critical  to  combat  success.  On  one  hand,  the  widespread 
information  sharing  that  is  inherent  in  the  JBI  is  likely  to  introduce  vulnerabilities,  but  on  the 
other,  centralized  control  of  information  may  have  advantages  in  providing  infonnation 
assurance.  The  infonnation  model  must  implement  applicable  security  policies,  such  as  support 
for  virtual  private  networks,  support  for  multi-level  security,  and  mechanisms  for  protection 
against  information  attacks. 

Security  is  an  extremely  complex  subject  which  must  be  a  central  focus  of  the  evolution  of  the 
JBI.  The  DII  COE  organization  at  DISA  has  placed  great  emphasis  on  ensuring  the  security  of 
the  platform  kernel,  which  is  one  important  consideration.  Other  approaches  include  the  concept 
of  Proof-Carrying  Code,  being  investigated  at  Carnegie  Mellon  University,  which  offers  a  way  to 
authenticate  that  a  server-provided  application  is  traceable  to  a  trusted  source.  Various  schemes 
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for  user  authentication,  including  the  DoD  initiative  in  Public  Key  Infrastructure  may  also 
contribute,  but  must  be  compatible  with  the  realities  of  the  battlefield,  including  the  hazard  that 
the  credentials  of  a  casualty  or  prisoner  of  war  may  fall  into  enemy  hands.  A  satisfactory 
security  architecture  for  the  JBI  will  include  functionality  allocated  at  every  level  from  the 
platform  operating  system  and  network  manager  to  trusted  applications  and  user  authentication. 

Rosenthal  and  Sciore  have  developed  extensions  to  Structured  Query  Language  (SQL)  that 
improve  controls  over  access  to  the  content  of  a  data  warehouse.  This  approach  appears  well 
matched  to  distributed  data  storage  and  large  numbers  of  users  and  controlling  authorities. 
Techniques  such  as  this  will  have  to  be  captured  and  expanded  to  achieve  a  robust  security 
strategy  for  the  JBI.  A  careful  analysis  of  vulnerabilities  and  their  mitigation  in  a  JBI  is  still  to 
be  accomplished.  Security  is  a  very  important  unsolved  problem  that  needs  a  great  deal  of 
attention  and  high  priority  for  resources. 

8.4.2. 7  Consistency  and  Replication 

The  JBI  information  base  will  be  geographically  distributed  and  multiply  instantiated.  It  is 
essential  that  the  information  model  provide  for  replication,  synchronization,  and  consistency 
enforcement  across  all  locations  where  common  data  is  stored.  It’s  also  important  that  a 
common  modeling  approach  be  used  for  data  coming  from  various  sources  and  data  provided  to 
applications.  An  important  aspect  is  likely  to  be  a  Transfonn  Library  that  contains  the 
information  on  such  things  as  unit  conversions  (for  example,  miles  to  kilometers),  file  format 
conversions  (for  example,  JPEG  to  GIF)  and  communications  protocol  translations.  Such  a 
library  would  be  extremely  useful  in  the  efficient  operation  of  the  fuselets  that  are  responsible  for 
the  multitude  of  content  transformations  required  by  the  JBI. 

8. 4. 2. 8  Quality  Assurance 

In  the  real  world,  data  will  be  imperfect,  whether  contaminated  by  errors,  aged  beyond  allowable 
latency  limits,  missing  parameters,  or  otherwise  deficient.  The  information  model  must  provide 
for  quality  checking  and  allow  data  to  be  accessed  with  appropriate  declarations  of  accuracy, 
timeliness,  trust  level  of  the  source,  and  so  forth.  When  the  information  model  yields  multiple 
inconsistent  answers  to  a  query,  the  appropriate  users  and  system  administrators  must  be 
informed. 

Another  essential  aspect  of  quality  relates  to  the  source  or  pedigree  of  a  given  information  object. 
The  level  of  trust  placed  in  the  source,  the  inherent  quality  of  the  sensor  or  observer  producing 
the  data,  the  extent  to  which  the  source  has  unhindered  access  to  the  event  or  location  being 
reported  on,  and  similar  factors  must  be  accounted  for  in  assigning  a  quality  metric.  This  is 
critical  when  independent  or  dissimilar  information  objects  must  be  fused,  remembering  that  the 
optimum  fusion  method  may  simply  be  to  pick  the  best  one  and  that  poorer  data  may  simply 
degrade  the  fused  result  if  used  indiscrimately. 

Quality  will  depend  critically  on  the  currency  and  accuracy  of  the  metadata  in  the  JBI  repository. 
Metadata  is  not  static  because  the  information  objects  themselves  will  be  constantly  changing.  A 
key  function  of  JBI  management  will  be  to  ensure  adequate  provisions  for  refreshing  and 
revalidating  metadata.  Tools  for  the  development,  editing,  and  export  of  metadata  are  beginning 


48  A.  Rosenthal  and  E.  Sciore,  “View  Security  as  the  Basis  for  Data  Warehouse  Security,”  Proc.  Int’l  Workshop  on 
Design  and  Management  of  Data  Warehouses  (DMDW  2000),  5-6  June  2000,  pp.  8-1  to  8-8. 
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to  emerge  for  electronic  business  and  other  applications  and  are  likely  to  be  important  in  dealing 
with  this. 

8. 4. 2. 9  Additional  Services 

Over  and  above  the  five  services  identified  in  the  manipulation  layer  of  Figure  8-1,  higher  order 
services  are  likely  to  evolve  to  make  the  JBI  more  efficient  and  useful.  A  “discovery”  service 
would  take  whatever  parameters  and  criteria  a  user  is  able  to  provide  about  desired  information 
and  conduct  an  intelligent  search  for  content  that  may  be  relevant.  A  “mediation”  service  would 
map  content  from  various  domains  and  in  various  formats  to  a  unifonn  interface  understandable 
by  all  users.  A  variety  of  “fusion”  services  can  be  envisioned,  ranging  from  association  and 
kinematic  merging  of  track  updates  to  combinations  of  dissimilar  or  uncorrelated  data  to  produce 
indications  and  warnings  messages  or  to  discover  previously  undetected  associations. 

8.4.2.10  Interfaces 

Last,  and  most  important,  the  JBI  information  model(s)  must  have  interfaces  that  facilitate  access 
to  services  by  each  user  community.  This  is  the  essence  of  ease  of  use,  because  good  interfaces 
make  the  details  of  the  information  infrastructure  transparent  to  operational  users.  Properly 
defined  and  implemented  interfaces  have  far  greater  impact  on  the  utility  of  the  JBI  than  the 
details  of  infonnation  manipulation  within  the  infosphere  (as  one  study  participant  puts  it, 
“Interfaces  are  more  important  than  algorithms.”)  For  maximum  interoperability,  the  JBI’s 
service  interfaces  must  be  implemented  in  a  language  that  supports  a  rich  array  of  functionality. 
The  best  example  today  is  probably  SQL,  with  the  good  possibility  that  an  XML  query  language 
will  emerge  in  the  near  future.  Properly  implemented  metadata  supports  the  generation  of 
connectivity  parameters  to  enable  efficient  and  rapid  support  for  publish  and  subscribe  actions. 

8.4.3  Interoperability 

A  user  or  platform  interacts  with  the  JBI  through  an  interface  defined  in  terms  of  publish  and 
subscribe  actions  which  invoke  the  corresponding  services  of  the  JBI  infonnation  model.  The 
JBI  interface  explicitly  allows  ad  hoc  queries  and  might  logically  be  extended  to  include  such 
things  as  attachments  to  messages  and  references  to  infonnation  locations.  This  is  the  essence  of 
interoperability  in  a  JBI  world — each  participant  deals  with  a  single,  well-defined  information 
provider  instead  of  with  a  combinatorially  complex  set  of  interfaces  to  other  participants.  The 
interface  can  be  thought  of  in  terms  of  an  interface  control  document  (ICD),  since  all  essential 
details  of  the  interaction  must  be  defined,  but  is  fundamentally  different  from  the  traditional 
definition  of  an  ICD.  Instead  of  the  detailed  prescription  of  signals,  bit  definitions,  and  timing 
relationships  of  a  classic  ICD,  the  JBI  interface  consists  of  the  information  service  interfaces, 
protocols  for  the  communication  services  employed,  and  protocols  for  security,  network 
management,  and  other  aspects  of  JBI  access. 

The  interface  is  hierarchical.  As  the  JBI  information  model  evolves  to  higher  levels  of 
abstraction,  the  top  level  comes  closer  to  natural  language.  Here,  it  is  easy  to  implement  both 
command  policies  for  information  dissemination  and  individual  user  information  needs.  At 
lower  levels,  details  of  the  information  and  data  structures,  the  communications  channels,  and  the 
implementation  of  security  procedures  must  be  dealt  with  by  system  designers.  At  every  level  of 
the  interface,  the  guiding  principle  is  a  fully  open,  flexible,  Internet-like  model  of  interaction  that 
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uses  appropriate  public  standards  where  they  apply  and  defines  new  ones  as  needed.  The  choice 
of  standards  for  publish  and  subscribe  will  be  especially  important. 

8.4.4  Centralized  vs.  Distributed  Control 

There  is  an  inherent  tension  in  the  JBI  construct  between  centralized  and  decentralized  control. 
From  the  perspective  of  commanders  and  their  forces,  it  is  essential  that  the  JBI  be  controlled  in 
such  a  way  that  the  quality  and  consistency  of  information  is  assured,  command  policies  are 
uniformly  applied,  and  a  fully  defined  interface  is  presented  to  every  user.  From  the  perspective 
of  the  system  developer,  centralized  program  management  of  such  a  large  and  diverse  system-of- 
systems,  built  up  by  the  incremental  incorporation  of  many  kinds  of  legacy  and  new  components, 
is  almost  certainly  unworkable.  Put  simply,  the  challenge  is  to  make  the  logical  view  appear  as  a 
single,  fully  integrated  information  services  provider  while  providing  for  decentralized  execution 
of  the  physical  implementation. 

The  solution  will  emerge  as  the  JBI  evolves,  but  some  general  principles  can  be  defined.  There 
will  have  to  be  centralized  control  of  the  JBI  operational  architecture,  especially  the  definition  of 
the  services  interfaces  presented  to  users.  There  will  also  have  to  be  mechanisms  for 
implementing  command  policy,  for  example,  for  “pushing”  certain  messages  to  specified 
recipients.  Similarly,  the  JBI  must  establish  global  rules  and  conventions  for  the  participation  of 
incorporated  components.  An  example  of  this  is  the  DTDs  that  define  the  SCR,  providing  a 
common  infonnation  representation  that  all  infonnation  providers  must  support.  Other  globals 
will  involve  rules  for  access  privileges,  definitions  of  information  quality  metrics,  and  any  other 
JBI  aspects  that  apply  across  the  involved  platforms,  systems  and  users. 

On  the  other  hand,  data  ownership,  interface  tailoring  for  individual  users,  maintenance  of 
individual  JBI  components,  and  the  like  require  distributed  control  of  important  JBI  features. 

The  next  section  of  this  discussion  addresses  the  physical  view  of  the  JBIs  and  some  practical 
considerations  involved  in  building  it,  which  also  call  for  decentralized  management.  The 
tension  will  be  resolved  by  allowing  decentralized  implementation  of  the  JBI  under  the 
operational  architecture  and  a  set  of  global  rules. 

8.5  Physical  Implementation  of  the  JBI 

The  logical  view  of  the  JBI  establishes  what  it  looks  like  to  warfighters  and,  thus,  how  it 
contributes  to  information-enabled  operations.  However,  the  physical  view  is  what  chiefly 
determines  the  feasibility,  complexity  and  cost  of  actually  building  the  infosphere.  Ultimately, 
the  JBI  is  created  by  computers  and  software,  networks  and  data  links,  human-machine 
interfaces,  and  other  assets  which  instantiate  JBI  information  services  and  their  interfaces.  As 
the  earlier  JBI  studies  have  stressed,  this  platfonn  environment  must  be  efficiently  designed  and 
effectively  managed  if  the  goal  of  seamless,  reliable  information  support  to  warfighters  is  to  be 
achieved. 

A  number  of  factors  make  the  JBI  a  formidable  undertaking.  It  must  scale  effectively  to  meet  the 
needs  of  a  wide  range  of  force  packages  and  missions.  The  turnover  of  technology  and  products 
and  the  practical  constraints  of  system  acquisition  mean  that  the  JBI  platform  will  be 
heterogeneous  and  will  continuously  evolve.  The  JBI  will  be  hosted  on  many  types  of 
computers,  operating  environments,  and  networks,  varying  from  platfonn  to  platform  and  node 
to  node.  Many  pieces,  some  new  and  some  legacy,  must  be  integrated  and  must  function 
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cooperatively  within  operational  timelines  and  with  the  requisite  continuity,  reliability,  security, 
and  quality  of  service. 

It  bears  repeating  that  one  of  the  keys  to  success  will  be  to  decouple  the  logical  view  with  its 
services  and  user  interfaces  from  the  evolving  physical  view  or  platfonn.  In  keeping  with 
current  best  practices  in  the  IT  world,  the  logical  view  of  the  JBI  must  be  captured  in  an 
operational  or  functional  architecture  that  is  independent  of  any  particular  implementation.  Then 
the  physical  view  is  documented  in  hardware  and  software  architectures  that  define  specific 
instantiations  at  various  nodes  within  the  InfoSphere.  This  concept  makes  it  easier  to  deal  with 
such  issues  as  the  use  of  information  exchange  protocols  as  the  primary  means  to  achieve 
interoperability  and  the  proper  role  of  the  DII  COE  in  helping  to  establish  a  suitable  platform 
foundation.  We  first  discuss  some  aspects  of  the  execution  platform  and  then  address  an 
approach  to  assembling  the  JBI  as  a  system,  or  confederation,  of  systems 

8.5.1  Platform  Architecture 

8. 5. 1.1  A  Role  for  a  Standardized  Execution  Platform 

An  infrastructure  defined  by  the  DII  COE  model  may  well  be  a  useful  tool  in  the  C  system 
developer’s  kit  bag.  For  reference,  Figure  8-5  is  the  standard  DII  COE  model  showing  the 
elements  of  the  environment.  Continued  DII  COE  use  will  be  more  viable  if  DISA  implements 
improvements  to  their  DII  COE  strategy  as  briefed  to  the  study  team.  Important  steps  would  be 
to  (1)  move  to  completely  COTS  kernels,  and  (2)  allow  commercial  procedures  (sometimes 
called  “logo  certification”  since  this  allows  a  vendor  to  put  the  appropriate  logo  on  a  product)  to 
be  used  to  satisfy  at  least  Level  5  compliance  certification.49  A  system  developer  who  finds  such 
a  platform  a  good  match  to  requirements,  a  way  to  economize  on  development,  and  a  way  to  get 
instant  interoperability  in  an  information  space  might  well  elect  to  adopt  it.  These  are  just  the 
sort  of  benefits  the  current  DII  COE  aims  to  deliver.  The  point  is  that  this  would  be  simply  an 
option  for  instantiation  of  the  platfonn  architecture,  not  the  central  strategy. 


49  DII  COE  compliance  below  Level  5  is  not  operationally  meaningful. 
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Figure  8-5.  Taxonomy  of  the  Dll  COE 


The  primary  route  to  interoperability  remains  the  information  services  model  and  the  exchange 
of  messages  through  the  publish/subscribe  interfaces  of  the  JBI.  JBI  services  will  be  provided  in 
a  CSE,  with  each  service  specified  by  its  interface,  including  metadata  and  other  format 
specifications  of  information,  procedures  and  constraints  for  invoking  the  service,  and  any  other 
required  elements.  The  CSE  might  well  be  implemented  on  DII  COE-compliant  platforms 
whose  details  are  transparent  to  JBI  users,  following  the  concept  of  decoupling  of  the  physical 
and  logical  views.  In  terms  of  the  DoD  C4ISR  Architecture  Framework,  the  DII  COE  is  an 
important  element  of  the  Technical  Architecture  while  the  CSE  is  a  major  part  of  the  System 
Architecture  and  mechanizes  user  requirements  from  the  Operational  Architecture. 

8. 5.1.2  Thin  Client  Networks 

The  history  of  multiuser  information  systems,  exemplified  in  C  systems  like  TBMCS,  is  one  of 
linking  user  workstations50  on  a  local  area  network  in  a  client-server  environment.  In  a  client- 
server  environment,  servers  are  used  to  store  and  manage  files,  provide  a  gateway  for  e-mail  and 
file  exchanges,  monitor  and  fine  tune  network  performance,  and  perform  other  system 
administration  chores  such  as  managing  user  accounts  and  controlling  access  privileges.  The 
primary  applications  reside  on  the  workstations,  although  to  save  license  fees  an  organization 
may  purchase  a  limited  number  of  “seats”  and  control  the  number  of  copies  of  a  program  that  are 
downloaded  at  one  time  for  use  on  workstations. 


50  Workstation  is  used  here  in  its  generic  sense,  not  just  to  mean  a  high  end  processor  used  for  functions  such  as 
computer-aided  design. 
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There  is  a  widespread  trend  in  infonnation  systems  generally  to  centralize  network  functionality 
on  powerful  servers  and  to  transfonn  workstations  into  access  devices  which  implement  tailored 
interfaces  to  network  services  for  individual  users.  The  idea  is  usually  called  a  “thin  client.” 

This  could  be  seen  as  a  throwback  to  the  early  days  of  networks  when  “dumb”  tenninals  logged 
on  to  a  mainframe  that  did  all  the  computing  and  storage.  It  can  also  be  criticized  on  the  grounds 
that  it  makes  an  organization  even  more  vulnerable  than  it  is  already  to  server  crashes,  network 
outages,  and  other  single  point  failures.  However,  the  thin  client  approach  has  powerful 
advantages.  Maintaining  consistency  of  shared  data,  common  configuration  of  shared 
applications,  common  and  fully  enforced  access  controls  and  intrusion  defenses,  and  other 
system-wide  features  is  easier.  A  thin  client  network  can  be  simpler  to  certify  for  classified 
processing  since  workstations  now  have  fewer  capabilities  to  support  malicious  behavior  like 
communications  outside  the  firewall.  In  general,  the  information  technology  community  seems 
to  be  moving  in  this  direction,  and  many  military  systems  are  exploring  the  feasibility  and 
benefits  of  the  thin  client  concept.  51 

Clearly,  the  thin  client  model  pertains  in  large  measure  to  a  logical  view  since  it  deals  with  how 
services  are  provided  to  users.  However,  it  also  has  major  physical  implications  since  it  drives 
such  things  as  the  nature  of  the  platform  employed  by  a  given  user,  the  capacity  of  the 
client/server  network,  and  the  choice  of  security  mechanisms. 

Shared  infonnation  services  are  at  the  heart  of  the  JBI  concept,  and  thus  a  network  of  powerful 
servers  and  thin  clients  looks  like  a  good  fit.  However,  care  in  implementation  is  essential.  A 
fighter  must  still  be  able  to  perform  its  mission  even  if  disconnected  from  the  JBI  by 
communications  failures  or  hostile  countenneasures.  Mission  planners,  weaponeers,  and 
intelligence  analysts  must  be  able  to  work  through  outages  in  the  networks  and  server  farms  of 
an  air  operations  center  (AOC).  Careful  system  engineering  is  required  to  map  functionality 
onto  servers,  workstations,  weapon  systems,  and  all  the  other  nodes  of  the  platfonn  environment 
and  to  ensure  robustness  under  real  world  conditions. 

8. 5. 1.3  Network  Computing 

With  the  concept  of  thin  clients  comes  that  of  network  computing.  Related  terms  are  web- 
enabled  applications  and  data  bases  and  application  service  providers.  In  each  case,  the  idea  is 
that  a  server  makes  data,  applications,  libraries  and  any  other  services  required  by  a  user  to 
perform  a  function  available  over  a  network.  Web-enabled  data  bases  using  XML  have  rapidly 
become  the  dominant  technique  for  information  sharing  in  such  areas  as  business-to-business 
commerce.  Web-enabled  applications  promise  to  make  greater  functionality  available  to  users. 
The  economic  argument  is  that  license  or  use  fees  will  be  smaller  than  the  outright  purchase  cost 
of  software.  A  relatively  small  set  of  standards  associated  with  the  basic  Internet  model,  together 
with  a  shared  programming  language,  are  the  basic  enablers  of  the  concept. 

The  primary  implementation  of  web  computing  today  uses  Java,  developed  by  Sun 
Microsystems.  Java  is  a  programming  language,  but  more  importantly,  it  is  a  client-server 
paradigm  in  which  a  virtual  machine  is  created  on  a  user  workstation  which  then  executes 
applications  from  the  server.  Since  the  virtual  machine  is  (in  principle)  identical  regardless  of 
the  computer  or  operating  environment  that  hosts  it,  Java  applications  are  (in  principle) 
universally  sharable.  There  are  issues  with  execution  speed  in  real  time  applications  because  the 

51  The  study  team  saw  an  example  in  use  aboard  the  3rd  Fleet  command  ship,  USS  Coronado. 
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normal  Java  mode  is  interpreted,  vs.  compiled,  meaning  that  the  workstation  must  do  multiple 
calculations  for  each  executed  instruction,  but  these  may  be  overcome  with  time.  Java  is  widely 
taught  in  schools  and  shows  signs  of  becoming  the  primary  programming  environment, 
especially  since  it  has  features  that  overcome  limitations  of  earlier  languages  like  C++.  It  is 
therefore  possible  that  network  computing  using  Java  will  be  a  major  feature  of  the  JBI  platform 
environment. 

8. 5. 1. 4  Component-Based  Architecture 

A  promising  approach  to  the  integration  of  a  platfonn  from  a  variety  of  products  is  the  notion  of 
treating  software  elements  as  components  with  fully  defined  interfaces  that  can  be  plugged  into 
an  operating  environment.  This  can,  in  fact,  take  the  form  of  defining  metadata  about  a 
component.  By  encapsulating  the  functionality  a  component  delivers  and  allowing  access  to  the 
services  it  provides  only  through  this  well-defined  interface,  conflicts  with  other  components  can 
be  minimized  and  the  process  of  invoking  component  services  through  an  interface  can  be 
simplified. 

8. 5.1. 5  Communications 

The  essence  of  the  JBI  is  the  exchange  of  information  within  the  InfoSphere  and  among  users. 
This  depends  on  robust,  timely  data  communications  through  a  set  of  links  and  networks  that 
form  a  common  communications  environment.  This  is  therefore  a  critical  element  of  the  JBI 
platform  environment.  One  of  the  key  functions  of  the  JBI  is  to  manage  the  connection  fabric 
and  the  traffic  on  it  so  as  to  best  satisfy  the  service  requirements  of  users. 

Two  important  concepts  here  are  “spontaneous”  or  “plug-and-work”  network  configuration  and 
self  annealing  networks.  The  first  of  these  means  that  an  eligible  user  can  join  a  network  simply 
by  connecting  to  it;  practical  details  such  as  address  assignment  are  automated.  In  the  Jini 
construct,  developed  by  Sun  as  the  networking  complement  to  Java,  a  service  wishing  to  join  a 
network  registers  with  a  “federation”  through  a  “lookup  service,”  and  clients  find  these  enrolled 
services  by  Java  type  from  the  lookup  service.  The  associated  code  then  moves  to  the  client 
from  the  lookup  service  like  any  network  application.  In  a  self  annealing  network,  service  is 
maintained  or  restored  after  failures  or  hostile  action  by  a  network  control  function  which 
establishes  links  and  routes  traffic  based  on  a  set  of  rules  and  the  available  communications 
paths.  In  any  case,  it  is  essential  that  the  nodes  of  the  infosphere  and  its  users  be  connected  by 
high  capacity,  redundant,  and  dynamically  managed  communications  channels  with  the 
responsiveness,  security  and  fault  tolerance  to  maintain  services  under  the  stress  of  operations. 

8.5.2  A  Migration  Path  to  the  JBI 

The  physical  structure  of  the  JBI  can  be  represented  as  an  assembly  of  mission-relevant  systems, 
which  become  the  components,  together  with  enabling  information  management  services,  all 
passing  infonnation  to  and  from  one  another.  Figure  8-6  illustrates  a  primitive  example  of  a  JBI. 
The  small  dark  outlined  ovals,  around  the  periphery  of  the  communications  mechanism,  called 
the  “Global  Information  Grid,”  represent  command  and  control  entities.  These  software¬ 
intensive  systems  provide  a  variety  of  services  to  users,  according  to  the  requirements  of  the 
organizations  that  bought  or  built  them.  C2  systems  and  supported  users  and  platforms  will  often 


52  As  currently  defined  by  DoD,  the  GIG  is  a  complete  information  infrastructure  similar  in  some  ways  to  the  JBI, 
but  the  communications  layer  of  that  infrastructure  is  what  is  of  interest  here. 
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need  to  exchange  information  with  each  other  in  order  to  perfonn  their  functions.  Such  message 
exchanges  have  traditionally  been  accomplished  over  dedicated  circuits  or  via  some  form  of 
network  that  could  handle  the  individual  point-to-point  infonnation  transfers.  The  GIG 
encompasses  a  variety  of  communications  paths,  including  the  Non-Secure  Internet  Protocol 
Router  Network,  Secret  Internet  Protocol  Router  Network,  and  JWICS  networks  that  provide  the 
primary  connection  fabric  of  the  GCCS. 


Figure  8-6.  A  Top-Level  Concept  of  the  JBI  as  a  Collection  of  Systems  and  Services  Interacting  via  the 

Global  Information  Grid 


For  the  JBI,  these  information  transfers  are  augmented  by  having  the  individual  systems  expose 
(publish)  their  information  in  a  manner  that  is  interpre table  by  the  other  JBI  participants.  If  a 
system  conforms  to  the  protocols  that  enable  information  to  be  interpreted  in  the  JBI,  then  that 
system  is  a  JBI  client.  In  addition,  since  it  is  essential  that  the  JBI  facilitate  the  migration  of 
legacy  systems  to  the  new  structure,  message  exchanges  are  allowed  through  a  variety  of  paths. 
The  normal  connectivity  is  via  the  shared  GIG  “cloud.”  However,  messages  can  also  be 
exchanged  through  “private”  channels  when  performance,  security,  or  other  considerations  so 
dictate.  Similarly,  legacy  system-to-system  connections  may  persist  when  this  helps  with  the 
assembly  and  functioning  of  the  JBI.  In  contrast  to  the  logical  view  in  Figure  8-4,  where  users 
are  at  the  top  of  the  hierarchy  and  the  information  repository  forms  the  foundation,  the  physical 
view  in  Figure  8-6  emphasizes  that  users,  systems,  and  the  nodes  that  provide  information 
storage  and  processing  can  all  be  thought  of  as  peers  since  each  is  a  client  of  the  JBI  interacting 
via  the  shared  network. 

The  light  colored  ovals  without  outlines  represent  services  or  “middleware”  that  enable  the  JBI 
to  function  efficiently  and  effectively.  The  individual  JBI  clients  are  made  aware  of  one  another 
via  one  of  the  JBI  enabling  facilities  that  serves  as  a  “broker.”  An  individual  JBI  client  will 
“publish”  information  that  it  anticipates  will  be  useful  to  other  JBI  clients.  The  published 
information  might  be  raw  information,  access  to  an  information  storage  area,  or  the 
announcement  of  a  service  that  the  JBI  client  can  offer  to  other  JBI  participants.  An  individual 
JBI  client  will  also  present  a  “subscription”  or  “query”  for  information  that  it  hopes  to  glean 
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from  the  JBI.  The  broker’s  task  is  to  match  the  publishments  with  the  subscriptions  and  to 
inform  both  parties  of  their  mutual  existence. 

Although  similar  in  concept  to  search  engines  used  on  the  Internet,  the  JBI  broker  is  a  bit  more 
sophisticated  because  it  will  make  the  pairwise  associations  of  publishments  and  subscriptions 
with  some  oversight.  The  oversight  may  encompass  rules  for  the  management  of  information, 
for  example,  command  policies.  These  policy  rules  may  prohibit  certain  publish/subscribe 
matches  and  require  others;  they  may  also  adjudicate  preferential  connections  for  yet  others.  In 
other  words,  the  broker  provides  its  services  according  to  policy  directives  and  rules  that  may  be 
changed  from  time  to  time  to  conform  to  the  commander’s  intent. 

The  JBI  broker  also  has  some  other  capabilities.  It  may  prioritize  the  pairwise  matches.  These 
priorities  might  be  established  by  the  commander,  but  they  may  also  be  established  through 
default  conditions.  Based  on  the  information  content  to  be  exchanged  over  the  JBI,  the  broker 
may  identify  some  transactions  as  higher  priority  than  others,  and  it  may  provide  that  priority 
hierarchy  to  the  communications  systems.  In  this  way,  the  communications  can  deliver  quality 
of  service  that  matches  the  specific  information  content  that  is  flowing  throughout  the  enterprise. 
As  the  JBI  evolves  and  technology  matures,  brokers  will  become  ever  more  competent,  adding 
services  like  discovery  and  fusion  as  were  described  in  Section  8. 4.2. 9. 

Finally,  as  alluded  throughout  the  logical  description  of  the  JBI,  other  information  management 
services  are  incorporated  in  the  JBI.  These  services,  also  represented  by  light  ovals  in  the 
Figure  8-6,  may  be  introduced  to  the  system  by  merely  incorporating  them  in  the  infosphere  as 
additional  clients.  Services  such  as  data  mediation  (implied  as  a  capability  to  achieve  the 
Structured  Common  Representation),  security  policy  services,  temporary  or  persistent  data 
storage  for  mission  relevant  capabilities  that  are  “information  storage  impaired,”  portals  for 
preparing  special  user-relevant  information  views  of  the  infosphere,  etc.  may  all  be  services  that 
can  be  added  to  the  JBI  as  the  level  of  sophistication  desired  escalates. 

The  effect  of  all  this  is  that  each  participant  or  client  o  the  JBI  sees  the  InfoSphere  through  a 
portal  that  mechanizes  the  particular  interactions  that  client  requires.  These  portals  are 
somewhat  analogous  to  personal  web  pages,  and  they  implement  the  tailored  services  interface 
appropriate  to  a  specific  JBI  participant.  They  combine  the  publish  and  subscribe  actions 
defined  by  user-established  criteria  with  actions  that  respond  to  central  policy,  such  as  “push”  of 
command-dictated  messages.  They  incorporate  a  mapping  of  the  InfoSphere  to  make  the 
fetching  and  storage  of  information  as  efficient  as  possible.  As  brokers  and  other  JBI  functions 
mature,  portals  offer  users  the  growing  range  of  services  described  above. 

An  important  physical  attribute  of  the  JBI  is  the  ability  to  introduce  new  capability  with  minimal 
impact  on  existing  systems.  With  current  system  structure,  new  capability  often  requires  an 
invasion  into  the  structure  of  an  existing  system  and  disassembly  of  functions  and  information  so 
that  the  new  capability  can  be  introduced.  With  the  JBI,  as  new  technology  and  new 
communications  mechanisms  surface,  the  novel  capabilities  can  subscribe  to  the  legacy 
information  repository  and  provide  new  information  objects  by  merely  publishing  into  the  JBI. 
Acceptance  and  exploitation  of  the  new  information  will  take  place  through  the  natural 
publish/subscribe  mechanisms  described  earlier.  The  ability  of  the  JBI  to  scale  is  assured  by 
keeping  the  physical  interfaces  simple,  by  decoupling  dependencies  upon  critical  elements,  and 
by  preserving  anonymity  among  participants. 
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In  Figure  8-4,  we  suggested  that  the  infonnation  content  of  the  JBI  would  be  logically  organized 
in  domains,  with  provisions  for  mapping  the  content  of  various  data  bases  into  an  SCR.  An 
analogous  concept  applies  here  in  considering  the  physical  structure  of  the  InfoSphere.  The 
various  JBI  clients  are  likely  to  elements  of  particular  functional  domains,  each  contributing  data 
and  information,  and  each  responsible  for  control  and  management  within  its  boundaries,  subject 
to  the  overall  rules  or  policies  governing  the  JBI  as  a  whole. 

Each  JBI  participant,  or  node,  in  Figure  8-6  could  be  implemented  as  an  individual  system  using 
a  layered  architecture  in  which  the  applications  comprising  the  node’s  functionality  ride  on  a 
node  platform.  The  platform  might  well  be  defined  by  a  version  of  the  DII  COE,  facilitating  the 
task  of  integrating  applications  within  the  node.  Such  an  implementation  will  be  assisted  if 
DISA  follows  through  on  plans  to  move  the  lower  levels  of  the  DII  COE  to  purely  commercial 
products  and  to  provide  for  technology  obsolescence  mitigation  and  long-term  backward 
compatibility.  The  larger  scale  of  interoperability  is  accounted  for  by  infonnation  exchanges 
through  the  GIG  or  over  other  links  and  networks,  using  an  Internet-like  set  of  protocols  and 
supporting  standards  for  publish  and  subscribe.  Techniques  described  earlier  in  this  chapter, 
including  XML  wrappers  for  legacy  data  bases  and  web-enabling  applications  will  be  central  to 
this  implementation  strategy. 

8.6  A  JBI  Strategy 

There  remains  the  question  of  choosing  and  executing  the  concrete,  feasible  actions  that  will 
power  the  migration  from  the  current  C  environment  to  the  JBI.  The  following  steps  might 
form  the  basis  for  such  a  strategy: 

•  Sponsor,  Define,  and  Lead  an  Evolutionary  Process.  There  are  too  many  unknowns  today  to 
define  the  JBI  information  model  and  services  in  detail.  Indeed,  as  noted  above,  there  is  no  final 
model,  because  the  warfighting  environment  itself  is  in  constant  flux.  Therefore,  what’s  needed 
is  to  involve  the  key  stakeholders  in  a  process  of  exploring  alternatives,  gathering  data  and 
experience,  evaluating  technologies  and  products,  choosing  standards,  and  incrementally  building 
and  demonstrating  the  JBI.  The  success  of  the  Internet  is  largely  based  on  the  fact  that  its 
standards  emerged  from  the  consensus  of  communities  of  interest,  and  a  process  like  that  of  the 
W3C  or  the  more  broadly  based  IETF  may  be  very  useful.  The  Air  Force  can  and  should  take 
this  on,  working  with  the  Joint  Staff,  Office  of  the  Assistant  Secretary  of  Defense:  Command, 
Control,  Communications,  and  Intelligence  (OASD/C3I),  (DISA),  the  other  Services,  DARPA, 
and  industry/academia.  This  is  the  overarching  activity,  of  which  the  remaining  actions  are 
components. 

•  Refine  the  JBI  Information  Model.  The  views  and  conclusions  expressed  in  this  discussion 
need  to  be  rigorously  challenged,  vetted  or  corrected,  and  refined  through  the  efforts  of  experts  in 
the  field  and  through  analyses  and  demonstrations  of  C2  systems.  The  right  information  model 
attributes,  the  right  set  of  implementing  standards,  the  right  information  assurance  model,  and  the 
right  way  of  presenting  information  services  to  C2  users  and  applications  are  key  questions 
needing  thorough  investigation,  including  in  operational  exercises  like  the  Joint  Expeditionary 
Force  Experiment.  A  key  issue  is  the  need  to  develop  a  method  whereby  the  system  can  associate 
a  unique  identifier  with  an  information  object  and  then  find  out  such  properties  as  the  object’s 
location,  type,  and  access  control  permissions. 

•  Migrate  Legacy  Systems  Toward  the  Model.  Existing  systems  intended  for  continued  use 
should  be  progressively  modified  toward  compliance  with  the  JBI  information  model  as  fast  as 
resources  will  permit.  The  goal  is  to  enable  these  systems  as  JBI  clients.  The  first  steps  are  to 
develop  XML  tags  for  the  data  bases  or  other  wrappers  that  allow  legacy  data  structures  to 
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interoperate  in  the  JBI  model,  and  to  web-enable  the  applications.  The  other  attributes  of  the 
model  can  be  progressively  implemented  as  the  model  matures. 

•  Migrate  the  DII  COE.  The  Air  Force  does  not  “own”  the  DII  COE  but  can  and  should  be  a 
leading  voice  for  the  agenda  of  migrating  toward  a  services-based  model,  with  standards  focused 
on  services  rather  than  products.  This  will  probably  entail  both  constructive  engagement  with 
DISA  (starting  with  agreement  at  the  Joint  Staff  and  OASD/C3I)  and  the  other  Services  and 
agencies  involved,  and  work  within  the  Air  Force  to  develop  the  JBI  information  model  and 
demonstrate  its  advantages.  A  central  element  of  this  is  to  move  away  from  the  current  DII  COE 
paradigm  of  exhaustive  standardization  of  platform  details  and  toward  an  Intemet-like  strategy. 
The  distributed  C4ISR  simulation  network  that  is  discussed  in  Chapter  1 1  of  this  report,  along 
with  applicable  Advanced  Concept  Technology  Demonstrations  (ACTDs),  actions  associated  with  the 
“AOC  as  a  weapon  system”  initiative,  updates  to  legacy  systems,  and  other  related  efforts  should 
be  coordinated  to  make  rapid  progress  toward  this  goal.  The  basic  idea  is  to  complement  the 
DII  COE  platform  standardization  strategy  with  the  logical  model  of  JBI  services  and  to  evolve 
DII  COE  toward  being  an  effective  JBI  platform  option 

•  Use  the  Adaptive  Battlespace  Awareness  ACTD  as  a  Vehicle.  The  current  focus  of  the  ACTD 
on  the  Common  Operating  Picture  is  appropriate,  and  any  expansion  of  the  ACTD  definition  to 
address  the  JBI  information  model  and  produce  the  evidence  to  support  migrating  the  DII  COE 
should  be  straightforward.  As  the  proposed  Experimental  AOC  at  Langley  Air  Force  Base  (AFB) 
takes  on  the  role  of  TBMCS  test  bed,  it  should  be  a  participant  and  might  be  the  logical  host  site 
for  the  ACTD.  Other  facilities  such  as  the  C2  Training  and  Innovation  Center  at  Hurlburt  AFB  and 
the  C2  Unified  Battlespace  Environment  at  Hansom  AFB  could,  over  time,  be  integrated  via 
broadband  links  into  the  distributed  C4ISR  network  to  enrich  the  participation  and  the  resources 
available  to  execute  the  ACTD. 

•  Cooperate  with  DARPA.  The  Air  Force  should  exploit  technologies  from  DARPA  programs  and 
partner  with  DARPA  to  speed  the  transition  of  these  into  JBI  implementation.  Among  other 
things,  this  could  provide  access  to  the  larger  IT  community  and  opportunities  to  influence  the 
content  of  emerging  standards  so  that  they  best  address  military  C2  needs. 

8.7  Summary 

The  future  of  Air  Force  C  ,  as  well  as  the  best  hope  of  achieving  the  goals  of  Joint  Vision  2020 
and  Vision  2020,  rest  with  the  JBI.  The  complexity  of  this  infonnation  system  is  unprecedented, 
but  the  technical  means  to  build  the  InfoSphere  are  rapidly  emerging.  The  greater  problems  are 
likely  to  be  political — reaching  a  consensus  within  the  Air  Force  and  then  across  DoD  on  the 
“business  model”  and  subordinating  individual  agendas  and  spheres  of  control  to  the  greater 
good.  The  JBI  will  come  about  through  a  steady  evolutionary  process  of  defining  and  refining 
the  infonnation  model,  incrementally  adding  systems  and  functionality,  validating  the  design  in 
exercises  and  operations,  and  institutionalizing  the  principles  and  practices  of  information- 
enabled  warfare.  There  can  be  few  more  critical  tasks  facing  the  Air  Force  in  the  years  ahead. 
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Chapter  9 
Summary 


9.1  Introduction 

There  is  no  doubt  in  the  minds  of  the  Air  Force  Scientific  Advisory  Board  (SAB)  that  the  Air 
Force  leaders  recognize  the  importance  of  the  effective  command  and  control  (C2)  of  its  forces  in 
achieving  success  in  air  operations.  There  is  also  a  profound  recognition  that  leadership  is 
understanding  that  air  forces  engaged  in  past  conflicts  have  not  benefited  from  the  awesome 
power  of  an  effective  theater  C  system  with  the  flexibility  and  responsiveness  necessary  in  the 
dynamic  battlespace  which  technology  has  brought. 

Implementing  the  necessary  changes  to  the  current  Theater  Air  Command  and  Control  System 
(TACCS)  involves  much  more  than  a  technical  (hardware  and  software)  change.  In  fact,  it 
requires  a  fundamental  change  in  “business  practices”,  to  borrow  a  commercial  tenn.  It  requires 
a  top-down  revision  in  thinking  and  in  accomplishing,  before  any  technical  changes  are  made. 

9.2  Leadership  Commitment 

During  the  course  of  the  Study,  the  team  reviewed  the  history  of  deficiencies  and  fixes  to  the 
TACCS.  There  have  been  numerous  studies,  including  four  SAB  Studies  in  the  last  five  years. 
There  have  been  organizations  and  re-organizations,  all  with  little  lasting  impact  on  the  state  of 
the  capabilities. 

A  fundamental  element  of  the  solution  must  be  a  commitment  on  the  part  of  leadership,  a 
commitment  to  not  only  initiate  actions  in  supporting  the  business  practice  change,  but  to  lay  in 
place  a  mechanism  for  high-level  review  and  follow-up  to  assure  actions  are  fully  completed, 
and  that  the  resulting  command  and  control  system  allows  for  evolution  as  the  technology 
advancements,  operational  concepts,  and  world  environment  dictate. 

We  are  encouraged  at  the  dedication  of  the  current  leadership — General  Michael  Ryan,  Chief  of 
Staff,  U.S.  Air  Force;  General  John  Jumper,  Commander,  Air  Combat  Command  (ACC);  and 
Major  General  Gerald  Perryman — in  recognizing  the  need  for  action,  as  well  as  both  the 
technical  and  operational  issues  associated  with  command  and  control  and  the  information 
technology  field.  Continued  attention  is  encouraged. 

9.3  Organizational  Change 

The  management  of  C  has  traditionally  been  spread  across  combat  and  support  mission  areas, 
boards/panels,  and  the  associated  organizational  structure  without  considering  the  essential  need 
for  a  C2  system  integrated  across  the  Air  Force.  Only  since  the  Air  Command  and  Control 
Agency  (AC2A),  now  the  Aerospace  Command  and  Control,  Intelligence,  Surveillance,  and 
Reconnaissance  Center  (AC2ISRC),  was  established  in  1997  has  there  been  any  serious 
consideration  of  the  need  to  concentrate  effort  in  the  area.  The  AC2ISRC  has  clearly  had  great 
impact  on  the  command  and  control  function,  finally  getting  its  arms  around  the  myriad  of 
concept  of  operations,  architectures,  programs,  program  elements,  and  people. 
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At  the  Air  Staff  level,  however,  there  remains  a  fragmentation  of  management  of  command, 
control,  communications,  intelligence,  surveillance,  and  reconnaissance  across  8  Panels,  131 
program  elements,  and  4  major  two-letter  directorates.  Moreover,  as  important  as  the  Center  is 
to  the  Commander  of  ACC  as  well  as  other  major  commands,  it  cannot  be  effective  without  a 
similar  consolidation  of  management  at  the  Air  Staff. 

Consolidation  of  the  management  of  C2  is  essential.  We  cannot  expect  that  the  proper 
management  trades  critical  to  a  constrained  budget  will  be  made  in  a  organizational  structure  in 
which  management  responsibilities  are  fragmented. 

9.4  Defining  Command  and  Control 

The  official  definition  of  command  and  control  is: 

“Command  and  control  is  the  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  and  attached  forces  in  the  accomplishment  of  the  mission.  Command 
and  control  functions  are  performed  through  an  arrangement  of personnel,  equipment, 
communications,  facilities,  and  procedures  employed  by  a  commander  in  planning,  directing, 
coordinating,  and  controlling  forces  and  operations  in  the  accomplishment  of  the  mission.  ” 
(Source:  Joint  Publication  1-02,  Department  of  Defense  Dictionary  of  Military  and  Associated 
Terms) 

So,  while  command  and  control  is  a  function,  the  many  hardware  and  non-hardware  elements 
that  enable  the  function  must  be  considered  in  the  management  and  modernization  process. 

9.5  Applying  Resources 

The  Air  Force  faces  a  critical  shortage  of  funds  for  operations  and  maintenance  (3400),  for 
system  development  (3600),  and  for  acquisition  (3080).  ft  is  not  likely  that  there  will  be 
significant  relief  in  the  foreseeable  future.  Thus,  the  Air  Force  must  assume  a  level  budget,  and 
carefully  allocate  the  funding  available  to  get  the  most  from  each  dollar.  We  submit  that  the 
current  process  involving  many  program  elements  and  no  single  Panel  to  represent  such 
activities  as  the  AC21SRC  to  assure  consideration  of  the  alternatives  as  well  as  to  prioritize  the 
initiatives,  is  not  an  appropriate  way  to  manage  limited  funds. 

•5 

Thus,  we  suggest  a  greatly  reduced  number  of  program  elements,  and  a  C  Panel  in  the  Board 
Structure  as  the  surest  way  to  success  in  solving  the  many  command  and  control  problems. 

9.6  Summary 

The  Air  Force  Scientific  Advisory  Board  recognizes  the  substantial  pressures  on  the  Air  Force  to 
do  more  with  fewer  resources.  Most  certainly,  the  effective  use  of  command  and  control  in  the 
management  and  control  of  air  operations  could  improve  the  efficiency  of  the  combat  forces. 

The  recommendations  included  in  this  report  are  the  collective  opinion  of  the  study  team. 
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Appendix  A  to  Volume  2 
Terms  of  Reference 

USAF  Scientific  Advisory  Board  2000  Summer  Study  on 
Air  Force  Command  and  Control  -  The  Path  Ahead 


2 

BACKGROUND:  The  Air  Force  needs  to  define  its  command  and  control  (C  )  system  in  light 
of  recent  points  of  experience  in  Operations  Desert  Shield/Desert  Storm  and  Operation  Noble 
Anvil  in  Kosovo,  taking  advantage  of  technological  improvements.  The  Air  Force  is  not  on  a 
path  today  that  provides  coherence  across  space,  air,  and  land  assets  to  support  the  most  timely 
and  effective  decision  making  and  execution.  The  USAF  Scientific  Advisory  Board  (SAB)  and 
other  defense  advisory  boards  have  conducted  a  number  of  studies  over  the  past  decade  that  bear 
directly  on  this  problem  and  form  a  foundation  from  which  to  work.  The  Board  is  now  being 
asked  to  assess  the  C  system  and  the  supporting  communication  and  information  systems,  to 
consider  technical  and  process  improvements,  and  to  make  recommendations  on  what  should  be 
done  to  “have  the  USAF  linked  by  2005”  and  to  build  toward  the  Air  Force’s  long  term 
command  and  control  goals. 

Study  Products:  Briefing  to  SAF/OS  &  AF/CC  in  October  2000.  Publish  report  in 
December  2000. 

Charter: 

6.  Define  the  Air  Force  command  and  control  system  with  today’s  capabilities  and  identify  alternatives 
to  enhance  it  over  time: 

•  Describe  operational  C2  concepts  and  procedures. 

•  Examine  functional  tasks  and  consider  where  these  tasks  should  be  accomplished  in  the 
organizational  construct. 

•  Determine  connectivity/network  requirements  for  the  defined  system  and  improved  systems,  and 
identify  where  today’s  systems  are  out  of  phase  or  disconnected. 

•  Include  the  integration  of  intelligence,  surveillance  and  reconnaissance  (ISR)  assets. 

7.  Define  interoperability  (joint  and  coalition)  to  ensure  coordinated  efforts  on  the  battlefield. 

8.  Identify  the  technologies  that  can  enhance  present  and  future  command  and  control  systems, 
with  near  term  emphasis  on  timely  and  effective  communication. 

9.  Assess  the  acquisition,  programmatic  and  cost  effectiveness  issues. 

10.  Consider  the  organizational,  personnel,  training  and  support  consequences. 

1 1 .  The  report  should  include  recommendations  on: 

•  Defining  a  specific  command  and  control  system  with  today’s  assets. 

•  Changes  in  the  system  possible  in  the  near  term  with  new  procedures  and  technology,  with 
emphasis  on  “having  the  USAF  linked  by  2005”. 

•  Longer-term  improvements  consistent  with  the  Air  Force’s  long-term  vision  for  command  and 
control. 
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Acronyms  and  Abbreviations 


AADC 

ABCCC 

ABCS 

ABIT 

AC2A 

AC2ISRC 

ACC 

ACO 

ACS 

ACTD 

ADOCS 

AEF 

AESA 

AF/DP 

AF/IL 

AF/SC 

AF/TE 

AF/XO 

AF/XOC 

AF/XOI 

AF/XO  J 
AF/XOR 

AF/XP 

AF/XPP 

AFATDS 

AFB 

AFDD 

AFFOR 

AFI 

AFMC 

AFOSR 

AFOTEC 

AFRL 

AFRL/IF 

AFSC 

AFSOC 

AF  SPACE 

AFSPACECOM 

AMC 

AMD 

AMDWS 

AMOCC 

AMPS 

AO 

AOC 

API 

AR 

ASAS 


Area  Air  Defense  Commander 

Airborne  Battlefield  Command  and  Control  Center 

Army  Battle  Control  System 

Airborne  Information  Transfer 

Air  Command  and  Control  Agency 

Aerospace  Command  and  Control,  Intelligence,  Surveillance,  and 
Reconnaissance  Center 
Air  Component  Commander 
Airspace  Control  Order 
Agile  Combat  Support 

Advanced  Concept  Technology  Demonstration 
Automated  Deep  Operations  Coordination  System 
Aerospace  Expeditionary  Force 
Active  Electronic  Scanned  Arrays 
Deputy  Chief  of  Staff,  Personnel 
Deputy  Chief  of  Staff,  Installations  and  Logistics 
Deputy  Chief  of  Staff,  Air  and  Space  Operations 
Headquarters  Air  Force,  Test  and  Evaluation 
Deputy  Chief  of  Staff,  Air  and  Space  Operations 
Deputy  Chief  of  Staff,  Air  and  Space  Operations,  Command  and 
Control 

Deputy  Chief  of  Staff,  Air  and  Space  Operations,  Intelligence, 
Surveillance,  and  Reconnaissance 
Deputy  Chief  of  Staff,  Air  and  Space  Operations,  Joint  Matters 
Deputy  Chief  of  Staff,  Air  and  Space  Operations,  Operational 
Requirements 

Deputy  Chief  of  Staff,  Plans  and  Programs 

Deputy  Chief  of  Staff,  Plans  and  Programs,  Programs 

Advanced  Field  Artillery  Tactical  Data  System 

Air  Force  Base 

Air  Force  Doctrine  Document 

Air  Force  Forces 

Air  Force  Instruction 

Air  Force  Materiel  Command 

Air  Force  Office  of  Scientific  Research 

Air  Force  Operational  Test  and  Evaluation  Center 

Air  Force  Research  Laboratory 

Air  Force  Research  Laboratory,  Information  Directorate 

Air  Force  Systems  Command 

Air  Force  Special  Operations  Command 

Air  Force  Space  Command 

Air  Force  Space  Command 

Air  Mobility  Command 

Air  Mobility  Division 

Air  Missile  Defense  Work  Station 

Air  Mobility  Operations  Control  Center 

Air  Mission  Planning  System 

Area  of  Operations 

Air  Operations  Center 

Application  Program  Interface 

Acquisition  Reform 

Army’s  All  Source  Analysis  System 
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ASC 

ASOC 

ASR 

ATACMS 

ATAF 

ATARS 

ATDL-1 

ATO 

AWACS 

BCC 

BCD 

BCS 

BGPHES 

C2 

C2IPS 

c2isr 

c2tig 

c2wac 

c3 


c4isp 

c4isr 

C/S/A 

C/JFACC 

CADM 

CAF 

CAIV 

CAOC 

CAS 

cc 

CCE 

CCO 

CCPDS-R 

CDE 

CDL 

CEC 

CFACC 

CHBDL 

CINC 

CIO 

CIS 

CJCSI 

CMM 

CoABS 

COD 

COE 

COMAFFOR 

COMAFSPACE 

COMPES 

CONOPS 

CONUS 


Aeronautics  Systems  Center 
Air  Support  Operations  Center 
Automated  Speech  Recognition 
Tactical  Missile  System 
Allied  Tactical  Air  Forces 

Advanced  Tactical  Airborne  Reconnaissance  System 
Army  Tactical  Data  Link-1 
Air  Tasking  Order 

Airborne  Warning  and  Control  System 
Battle  Control  Center 
Battlefield  Coordination  Detachment 
Battle  Control  System 

Battle  Group  Passive  Horizon  Extension  System 
Command  and  Control 

Command  and  Control  Information  Processing  System 
Command,  Control,  Intelligence,  Surveillance,  and  Reconnaissance 
Command  and  Control  Training  and  Innovation  Center 
Command  and  Control  Warrior  Advanced  Course 
Command,  Control,  and  Communication 
Command,  Control,  Communications,  and  Intelligence 
Command,  Control,  Communications,  and  Computers 
Command,  Control,  Communications,  Computers,  and  Intelligence 
Command,  Control,  Communications,  Computers,  and  Intelligence 
Support  Plan 

Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance 
Commander  in  Chiefs,  Services  and  Agencies 
Combined/Joint  Force  Air  Component  Commander 
Core  Architecture  Data  Model 
Combat  Air  Force 
Cost  as  an  Independent  Variable 
Combined  Aerospace  Operations  Center 
Close  Air  Support 
Commander 

Common  Communications  Environment 
Chief,  Combat  Operations 

Command  Center  Processing  and  Display  System-Replacement 

Common  Data  Environment 

Common  Data  Link 

Cooperative  Engagement  Capability 

Combined  Forces  Air  Component  Commander 

Common  High-Bandwidth  Data  Link 

Commander  in  Chief 

Chief  Information  Officer 

Combat  Intelligence  System 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 

Capability  Maturity  Model 

Control  of  Agent  Based  Systems 

Combat  Operations  Division 

Common  Operating  Environment 

Air  Forces  Commander 

Commander  Air  Force  Space  Command 

Contingency  Operations  Mobility  Planning  and  Execution  System 
Concept  of  Operations 
Continental  United  States 
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COP 

COTS 

CRC 

CRD 

CRE 

CSAF 

CSAR 

CSE 

CSP 

CSS1 

CSS2 

CT 

CTAPS 

CUBE 

DAC 

DAML 

DARPA 

DASC 

DASR 

DCAPES 

DCGS 

DCO 

DCS 

DDDS 

DEP 

DFAD 

DIA 

DII 

DII  COE 
DIRMobFor 
DISA 
DMB 

DMPI 

DMRE 

DMS 

DMT 

DOCC 

DoD 

DoDD 

DODIIS 

DP&E 

DT 

DT&E 

DTD 

EA 

EA/SD 

EAF 

ECM 

EO 

EOC 

EPLRS 

ESC 

EUCOM 
FA  AD 
FAC-A 


Common  Operating  Picture 
Commercial-Off-the-Shelf 
Control  and  Reporting  Center 
Capstone  Requirements  Document 
Control  and  Reporting  Element 
Chief  of  Staff,  United  States  Air  Force 
Combat  Search  and  Rescue 
Common  Services  Environment 
Communications  Support  Processor 
Common  Sensor  System  One 
Common  Sensor  System  Two 
Continuation  Training 

Contingency  Theater  Automated  Planning  System 

Command  and  Control  Unified  Battlespace  Environment 

Designated  Acquisition  Commander 

DARPA  Agent  Markup  Language 

Defense  Advanced  Research  Projects  Agency 

Direct  Air  Support  Center 

Direct  Air  to  Satellite  Relay 

Deliberate  Contingency  Action  Planning  and  Execution  System 

Distributed  Common  Ground  System 

Director  of  Combat  Operations 

Deputy  Chief  of  Staff 

Defense  Data  Dictionary  System 

Distributed  Engineering  Plant 

Digital  Feature  Analysis  Data 

Defense  Intelligence  Agency 

Defense  Information  Infrastructure 

Defense  Information  Infrastructure  Common  Operating  Environment 

Director  Mobility  Forces 

Defense  Information  Systems  Agency 

Department  of  Defense  Intelligence  Information  System  Management 
Board 

Desired  Mean  Point  of  Impact 

Dynamic  Mission  Readiness  Environment 

Defense  Message  System 

Distributed  Mission  Training 

Deep  Operations  Coordination  Cell 

Department  of  Defense 

Department  of  Defense  Directive 

Department  of  Defense  Intelligence  Information  System 

Dynamic  Planning  and  Execution 

Development  Test 

Development  Test  and  Evaluation 

Document  Type  Definition 

Evolutionary  Acquisition 

Evolutionary  Acquisition/Spiral  Development 

Expeditionary  Air  Force 

Electronic  Countermeasures 

Electro-Optical 

Enroute  Operations  Center 

Enhanced  Position  Location  Reporting  System 

Electronic  Systems  Center 

European  Command 

Forward  Area  Air  Defense  Data  Link 

Forward  Air  Control-Airborne 
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FDL 

Forward  Area  Air  Defense  Data  Link 

FIOP 

Family  of  Integrated  Operational  Pictures 

FLEX 

Force  Level  Execution 

FLOT 

Forward  Line  of  Own  Troops 

FOA 

Field  Operating  Agency 

FOPEN 

Foliage  Penetration 

GBDL 

Ground  Based  Data  Link 

GCCS 

Global  Command  and  Control  System 

GCCS-A 

Global  Command  and  Control  System- Army 

GCCS-AF 

Global  Command  and  Control  System- Air  Force 

GCCS-M 

Global  Command  and  Control  System-Maritime 

GCSS-AF 

Global  Combat  Support  System-Air  Force 

GDSS 

Global  Deployment  Support  System 

GIG 

Global  Information  Grid 

GMTI 

Ground  Moving-Target  Indication 

GOTS 

Government-Off-the-Shelf 

HQ 

Headquarters 

HRR 

High  Range  Resolution 

HSI 

Human-System  Interface 

HTML 

Hypertext  Markup  Language 

I&I 

Integration  and  Interoperability 

I&RTS 

Integration  and  Run  Time  Specification 

IA 

Information  Assurance 

IBS 

Integrated  Broadcast  Service 

ICD 

Interface  Control  Document 

IDL 

Interoperable  Data  Link 

IDM 

Information  Dissemination  Management 

IER 

Information  Exchange  Requirement 

IETF 

Internet  Engineering  Task  Force 

IJMS 

Interim  JTIDS  Message  Specification 

IKIWISI 

I’ll  Know  It  When  I  See  It 

IM 

Information  Management 

IMS 

Information  Management  System 

IO 

Information  Operations 

IOC 

Initial  Operating  Capability 

IOP 

The  Interoperability  Panel 

IP 

Internet  Protocol 

IPB 

Intelligence  Preparation  of  the  Battlefield 

IPT 

Integrated  Product  Team 

IQT 

Initial  Qualification  Training 

IR 

Infrared 

ISC2 

Integrated  Space  Command  and  Control 

ISR 

Intelligence,  Surveillance,  and  Reconnaissance 

ISSE 

Information  Support  Server  Environment 

IT 

Information  Technology 

IT-21 

Information  Technology-21 

IVIS 

Intra  Vehicular  Info  System 

IW 

Information  Warfare 

IWC 

Information  Warfare  Center 

J/CAOC 

Joint/Combined  Aerospace  Operations  Center 

J/CFACC 

Joint/Combined  Force  Air  Component  Commander 

JAC2C 

Joint  Aerospace  Command  and  Control  Course 

JACAC 

Joint  Aerospace  Computer  Applications  Course 

JAOC 

Joint  Aerospace  Operations  Center 

JASAC 

Joint  Aerospace  Systems  Administrator  Course 

JBI 

Joint  Battlespace  InfoSphere 
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JCSAR 

Joint  Combat  Search  and  Rescue 

JCTN 

Joint  Composite  Tracking  Network 

JDEP 

Joint  Distributed  Engineering  Plant 

JDN 

Joint  Data  Network 

JEFX 

Joint  Expeditionary  Force  Experiment 

JFACC 

Joint  Forces  Air  Component  Commander 

JFC 

Joint  Forces  Commander 

JGAT 

Joint  Guidance  Apportionment  &  Targeting 

JIEO 

Joint  Information  Engineering  Organization 

JITC 

Joint  Interoperability  Test  Center 

JITF 

Joint  Integration  and  Test  Facility 

JMA 

Joint  Mission  Architectures 

JMPS 

Joint  Mission  Planning  System 

JOA 

Joint  Operational  Architecture 

JointSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

JOTS 

Joint  Operational  Tactical  System 

JP 

Joint  Publication 

JPN 

Joint  Planning  Network 

JPO 

Joint  Program  Office 

JSA 

Joint  System  Architecture 

JSF 

Joint  Strike  Fighter 

JSRC 

Joint  Search  and  Rescue  Center 

JSSC 

Joint  Air  Operations  Senior  Staff  Course 

JTA 

Joint  Technical  Architecture 

JTF 

Joint  Task  Force 

JTDLMP 

Joint  Tactical  Data  Link  Management  Plan 

JTIDS 

Joint  Tactical  Information  Distribution  System 

JTRS 

Joint  Tactical  Radio  System 

JV2010 

Joint  Vision  2010 

JV2020 

Joint  Vision  2020 

KPP 

Key  Performance  Parameter 

LCA 

Life  Cycle  Architecture 

LD/HD 

Low  Density /High  Demand 

LMMS 

Lockheed  Martin  Mission  Systems 

LOCIS 

Logistics  Control  and  Information  Support 

LOS 

Line  of  Sight 

LRP 

Limited  Response  Package 

LWCDL 

Lightweight  Common  Data  Link 

MAJCOM 

Major  Command 

MAP 

Mission  Area  Plan 

MASC 

Modeling,  Analysis,  and  Simulation  Center 

MCS 

Maneuver  Control  System 

MDA 

Milestone  Decision  Authority 

MECDL 

Mission  Equipment  Control  Data  link 

METL 

Mission-Essential  Task  List 

METOC 

Meteorology  and  Oceanography 

MIDB 

Military  Integrated  Data  Base 

MIDS 

Multifunction  Information  Distribution  System 

MLS 

Multilevel  Security 

MRDL 

Multi-Role  Data  Link 

MQT 

Mission  Qualification  Training 

MS&A 

Modeling,  Simulation,  and  Analysis 

MTE 

Moving-Target  Exploitation 

MTS 

Marine  Tactical  System 

MX 

Military  Experimental 

N/UWSS 

NORAD/USPACECOM  Warfighting  Support  System 
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NAF 

NATO 

NGO 

NIMA 

NMCC 

NORAD 

NRO 

NS  A 

O&M 

OASD/C3I 

OPS 

ORD 

OSC 

OSD 

OT 

OT&E 

OTA 

OTS 

PACOM 

PADIL 

PE 

PEO 

PLRS 

PM 

PMD 

PME 

POM 

POSIX 

QRP 

R&D 

RF 

ROE 

ROTC 

RTIP 

S/GA 

S&T 

SAB 

SADL 

SAE 

SAF 

SAF/AQ 

SAF/AQI 

SAR 

SATCOM 

SBIR 

SCDL 

SCR 

SD 

SDM 

SEAD 

SEI 

SHADE 

SIGINT 

SIPRNET 

SODO 


Numbered  Air  Force 
North  Atlantic  Treaty  Organization 
Non-Government  Organizations 
National  Imagery  and  Mapping  Agency 
National  Military  Command  Center 
North  American  Air  Defense  Command 
National  Reconnaissance  Office 
National  Security  Agency 
Operations  and  Maintenance 

Office  of  the  Assistant  Secretary  of  Defense:  Command,  Control, 
Communications,  and  Intelligence 
Operations 

Operational  Requirements  Documents 
Operational  Support  Center 
Office  of  the  Secretary  of  Defense 
Operational  Test 
Operational  Test  and  Evaluation 
Operational  Test  Agency 
Officer  Training  School 
Pacific  Command 

Patriot  Automated  Digital  Information  Link 

Program  Element 

Program  Executive  Officer 

Position  Location  Reporting  System 

Program  Manager 

Program  Management  Directive 

Professional  Military  Education 

Program  Objective  Memorandum 

Portable  Operating  System  for  Information  Exchange 

Quick  Response  Package 

Research  and  Development 

Radio  Frequency 

Rules  of  Engagement 

Reserve  Officer  Training  Corps 

Radar  Technology  Improvement  Program 

Situation  and  Global  Awareness 

Science  and  Technology 

Air  Force  Scientific  Advisory  Board 

Situation  Awareness  Data  Link 

Service  Acquisition  Executive 

Assistant  Secretary  of  the  Air  Force 

Assistant  Secretary  of  the  Air  Force,  Acquisition 

Assistant  Secretary  of  the  Air  Force,  Information  Dominance 

Synthetic  Aperture  Radar 

Satellite  Communications 

Small  Business  Innovative  Research 

Surveillance  and  Control  Data  Link 

Structured  Common  Representation 

Spiral  Development 

Spiral  Development  Model 

Suppression  of  Enemy  Air  Defenses 

Software  Engineering  Institute 

Shared  Data  Engineering 

Signals  Intelligence 

Secret  Internet  Protocol  Router  Network 
Senior  Offensive  Duty  Officer 
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SPAWAR 

U.S.  Navy  Space  and  Naval  Warfare  Systems  Command 

SPINS 

Special  Instructions 

SPO 

System  Program  Office 

Sq  Km 

Square  Kilometer 

SQL 

Structured  Query  Language 

SWPS 

Strategic  War  Planning  System 

T&E 

Test  &  Evaluation 

TACC 

Tanker  Airlift  Control  Center 

TACCS 

Theater  Aerospace  Command  and  Control  System 

TACCSF 

Theater  Air  Command  and  Control  Support  Facility 

TACFIRE 

Tactical  Fire  Direction  System 

TACP 

Tactical  Air  Control  Party 

TAGS 

Theater  Air  Control  System 

TADIL-J 

Tactical  Digital  Information  Link  J 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TAIS 

Tactical  Air  Information  System 

TALCE 

Tanker  Airlift  Control  Element 

TBMCS 

Theater  Battle  Management  Core  System 

TCP 

Transmission  Control  Protocol 

TCP/IP 

Transmission  Control  Protocol/Internet  Protocol 

TCT 

Time-Critical  Targeting 

TIE 

Technology  Integration  Experiment 

TPFDD 

Time  Phased  Force  Deployment  Data 

TRP 

Theater  Response  Package 

TSPR 

Total  System  Performance  Responsibility 

TTPs 

Tactics,  Training  and  Procedures 

TULIP 

Through  Life  Interoperability  Planning 

UAV 

Unmanned  Aerial  Vehicle 

UGS 

Unattended  Ground  Sensors 

UHF 

Ultrahigh-Frequency 

UHR++ 

Ultrahigh  Resolution 

USAF 

United  States  Air  Force 

use 

University  of  Southern  California 

USCINCSPACE 

Commander  in  Chief  United  States  Space  Command 

USMTF 

U.S.  Message  Transmission  Format 

USN 

United  States  Navy 

USSPACECOM 

United  States  Space  Command 

USSTRATCOM 

U.S.  Strategic  Command 

UTC 

Unit  Type  Codes 

VMF 

Virtual  Message  Format 

VTC 

Video  Teleconferencing 

W3C 

World  Wide  Web  Consortium 

wees 

Wing  Command  and  Control  System 

woe 

Wing  Operations  Center 

XML 

Extendable  Markup  Language 
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Appendix  C  to  Volume  2 
Study  Organization 


Study  Chairman 

Dr.  Peter  R.  Worch 

Vice  Study  Chairman 

General  James  P.  McCarthy,  USAF  (Ret) 

SAB  Military  Director 

Lt  Gen  Stephen  B.  Plummer 

General  Officer  Participant 

General  John  P.  Jumper 

SAB  Executive  Director 

Col  Gregory  H.  Bishop 

SAB  Study  Executive  Officer 

Capt  D.  Brent  Morris,  AF/SB 

Panel  Chairs 

Concept  and  System  Definition  Panel:  Lt  Gen  Joseph  Hurd,  USAF  (Ret) 
Interoperability  Panel:  Dr.  John  M.  Borky 
Technology  Panel:  Dr.  Alison  K.  Brown 

Acquisition  and  Program  Management  Panel:  Maj  Gen  Eric  Nelson,  USAF  (Ret) 
People  and  Organization  Panel:  Mr.  Jeffery  B.  Erickson 
Vision  and  Bridging  Concepts  Panel:  Mrs.  Natalie  W.  Crawford 
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Concept  and  System  Definition  Panel 


Lt  Gen  Joseph  E.  Hurd,  USAF  (Ret),  Chair 
Private  Consultant 

Maj  Gen  John  A.  Corder,  USAF  (Ret) 

Private  Consultant 

Mr.  Troy  Crites 
Sparta,  Inc. 

Dr.  Llewellyn  S.  Dougherty 
Director  of  Technology 
Raytheon  Electronic  Systems 

Mr.  Jim  Hale 
Private  Consultant 

Maj  Gen  John  Hawley,  USAF  (Ret) 

Private  Consultant 

Mr.  David  Hess 

AC2ISRC 

MITRE 

Col  Stu  Kraft,  USAF  (Ret) 

Director,  Business  Development 

Northrop  Grumman/Logicon  Technical  Solutions 

Maj  Robert  Lanahan 

Branch  Chief,  Future  Communications  Systems 
National  Reconnaissance  Office 

Prof.  Alexander  H.  Levis 
Professor 

George  Mason  University 

Prof.  Christine  Mitchell 

Professor 

Georgia  Tech 

Maj  Robin  Morris 
AC2ISRC/C2A 

Col  Wayne  Ranne 
AC2ISRC/C2X 

Col  Mike  Reavey,  USAF  (Ret) 

Private  Consultant 
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Mr.  Skip  Saunders 
Executive  Director 
MITRE 

Prof.  Gene  Spafford 
Professor 
Purdue  University 

Col  Carl  Van  Pelt,  USAF  (Ret) 

Private  Consultant 

Lt  Gen  Ronald  Watts,  USA  (Ret) 

President 

Leadership  Development  Services 

Executive  Officer:  Capt  Larry  W.  Norman,  Jr.,  AC2ISRC/C2RO 
Technical  Writer:  Maj  Thomas  Schorsch,  USAFA 
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Interoperability  Panel 


Dr.  John  M.  Borky,  Chair 

Chief  Scientist 

Tamarac  Technologies,  LLC 

RADM  John  R.  Batzler,  USN  (Ret) 

Senior  Warfighting  Analyst 
Center  for  Naval  Analyses 

Prof.  Claude  R.  Canizares 
Director,  Center  for  Space  Research 
Massachusetts  Institute  of  Technology 

Mr.  Steve  Cox 

Lead  Communications  Engineer 
MITRE 

Dr.  Gary  A.  Federici 

Director,  Information  Operations  and  Warfare 
Center  for  Naval  Analyses 

Mr.  Thurman  (Rich)  Haas 

Principal  Director,  National  Systems  Engineering  and  Architecture  Directorate 
The  Aerospace  Corporation 

Lt  Gen  John  B.  Hall,  Jr.,  USAF  (Ret) 

Private  Consultant 

Dr.  Barry  M.  Leiner 
Director 

Research  Institute  for  Advanced  Computer  Science 

Lt  Col  Russel  M.  Mayes 

Chief,  Airborne  Communications 

AFCIC/SYOA 

Col  John  J.  Murphy,  Jr.,  USAF  (Ret) 

Staff  Principal  Analyst 
Aerospace  C2  &  ISR  Center  (ARINC) 

Dr.  Michael  P.  Shatz 

Leader,  Advance  Systems  Concepts  Group 
M.I.T.  Lincoln  Laboratory 

Executive  Officer:  Capt  Cristina  Huerta,  AFRL/VASM 
Technical  Writer:  Maj  David  E.  Bossert,  USAFA 
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Technology  Panel 


Dr.  Alison  K.  Brown,  Chair 
President 

NAVSYS  Corporation 

Dr.  Thomas  A.  Brackey,  Deputy  Chair 
Executive  Director,  Technical  Operations 
Hughes  Space  and  Communications  Company 

Dr.  Duane  A.  Adams 
Vice  Provost  for  Research 
Carnegie  Mellon  University 

Mr.  Timothy  M.  Bonds 
Analyst 

The  RAND  Corporation 

Mr.  John  N.  Entzminger 
Private  Consultant 

Dr.  Gene  H.  McCall 
Chief  Scientist 
AFSPACECOM 

Prof.  Alan  S.  Willsky 

Department  of  Electrical  Engineering  and  Computer  Science 
Massachusetts  Institute  of  Technology 

Maj  Kenneth  S.  Kreit 

Program  Manager,  Large  Aperture  Spacecraft 
National  Reconnaissance  Office 

Advisors:  Dr.  Kevin  B.  Kreitman,  Aerospace  Corporation 

Mr.  Richard  Metzger,  AFRL/IF 
Mr.  Jay  Scarano,  MITRE  Corporation 
Maj  Michael  J.  Estes,  C2ISR  Center 
Maj  William  Richard,  SAF/AQII 

Executive  Officer:  Maj  Timothy  P.  Nickerson,  AMC/XPX 
Technical  Writer:  Maj  Joseph  E.  Brouillard,  USAFA/IG 
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Acquisition  and  Program  Management  Panel 


Maj  Gen  Eric  B.  Nelson,  USAF  (Ret),  Chair 
Consultant 

Aerospace  Industry  Consulting  Services 

Mr.  Thomas  N.  Bostelaar 

Manager,  C2  Integration  Line  of  Business 

TRW  Systems  and  Information  Technology  Group 

Col  John  J.  Colligan,  USAF  (Ret) 

Acquisition  Systems  Advisor 
MITRE  Air  Force  C3  Systems  Center 

Lt  Gen  Gordon  E.  Fornell,  USAF  (Ret) 

Consultant 

Dayton  Aerospace  Inc. 

Maj  Gen  George  B.  Harrison,  USAF  (Ret) 

Director,  Research  Operations 
Georgia  Tech  Research  Institute 

Dr.  Mark  A.  Lorell 
Senior  Analyst 

Rand  Corporation,  Santa  Monica 

Dr.  Kenneth  C.  Pedersen 

Vice  President,  Advanced  Missile  Systems 

Raytheon  Missile  Systems  Division 

Dr.  Harold  W.  Sorenson 
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Appendix  D  to  Volume  2 
Top  Level  Organizations  Visited 


7-8  March,  Colorado  Springs,  CO,  Acquisition  Panel 

Lockheed  Martin,  Colorado  Springs20-21  March,  Hurlburt  Field,  FL,  all  panels 
C2TIG,  AC2ISRC,  ESC,  JointSTARS,  C2ISR  Acq,  C2  Battlelab,  JEFX  2000,  SAF/AQI 

22-24  March,  Robins  AFB,  GA,  People  and  Organization  Panel 

93rd  Air  Control  Wing 

27-28  March,  Orlando,  FL,  People  and  Organization  Panel 

Air  Force  Agency  for  Modeling  and  Simulation 

3-5  April,  Hanscom,  MA,  Acquisition  Panel 

ESC 

10-11  April,  Langley  AFB,  VA,  all  panels 

ACC  Headquarters,  AC2ISRC,  ACC  Network  Operations  Security  Center 

10-12  April,  Hampton,  VA,  Interoperability  Panel 

JFCOM,  JWC,  JBC13-14  April,  Washington  DC,  People  and  Organization  Panel 

Lockheed  Martin,  Boeing  Infonnation  Systems,  US  Navy,  DARPA 

18-20  April,  Washington  DC,  Acquisition  Panel 

SAF/AQ,  DISA,  DOE 

25-27  April,  Nellis  AFB,  NV,  all  panels 

Air  Warfare  Center,  Space  Warfare  Center,  Red  Flag,  ESC  Programs,  Boeing  IRAD,  USAF 
Fighter  Weapons  School 

28  April,  Colorado  Springs,  CO,  Acquisition  Panel 

Lockheed  Martin 

3-4  May,  Hurlburt  Field,  FL,  Concept  and  System  Definition  Panel 

c2tig 
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8-12  May,  Las  Vegas,  NV,  Concept  and  System  Definition  Panel 

Agile  Combat  Support  Conference 

8-12  May,  Washington  DC,  Acquisition  Panel 

AFCEA  sponsored  Global  Command  and  Control  System  course 

16-17  May,  Chantilly,  VA,  Interoperability,  Technology,  and  Concept  and  System 
Definition  Panels 

NRO,  DARPA 

16-18  May,  Washington  DC,  Acquisition  Panel 

DISA,  USAF/XOC,  SPA  WAR,  USAF/XOJ,  SAF/AQI,  USAF/XOR,  USAF/SC,  and  USAF/XPP 

18  May,  Washington  DC,  Concept  and  System  Definition  Panel 

DARPA 

18  May,  Crystal  City,  VA,  Interoperability  Panel 

Lockheed  Martin,  OASD/C3I,  JSF  Program  Office 

23-25  May,  Langley  AFB,  VA,  Technology  Panel 

Fusion  Briefings 

30  May-1  Jun,  Wright-Patterson  AFB,  OH,  People  and  Organization  Panel 

AFRL  Human  Effectiveness  Directorate 

7-9  June,  Davis  Monthan  AFB,  AZ,  Concept  and  System  Definition  Panel 

12  June,  Rome,  NY,  People  and  Organization,  Interoperability,  Technology,  and 
Concept  and  System  Definition  Panels 

AFRL  Information  Directorate 

13-14  June,  Hanscom  AFB,  MA,  all  panels 

ESC 

21  June,  Washington  DC,  Interoperability  Panel 

HQ  US  Army/DISC4 

21-22  June,  Langley,  AFB,  VA,  Technology  Panel 

ISR  Briefings 
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26-27  June,  Interoperability  and  Technology  Panels 

SPAWAR  System  Center,  SPAWAR  Acquisition,  SWC 

26- 27  June,  Washington  DC,  Acquisition  Panel 

DISA,  Ballistic  Missile  Defense  Organization,  SPAWAR,  and  Advance  Information  Technology 
Service  Joint  Program  Office 

27- 30  June,  Seattle,  WA,  People  and  Organization  and  Concept  and  System 
Definition  Panels 

Boeing  Phantom  Works,  Space  and  Communication 

30  June,  Ft  Monmouth,  NJ,  Interoperability  Panel 

Army  PEO/C3S 

10-21  July,  San  Jose,  CA,  all  panels 

SAB  Summer  Session 

10-21  July,  San  Jose,  CA,  Technology  Panel 

Oracle  Corporation,  Sun  Microsystems,  JavaSoft,  TBMCS  Briefing 

17  July,  San  Diego,  CA,  Interoperability,  People  and  Organization,  and  Concept 
and  System  Definition  Panels 

US  Navy  Command  Ship  Coronado 

7  August,  Wright-Patterson  AFB,  OH,  Acquisition  Panel 

AFMC  HQ,  ESC,  ASC 
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Appendix  4D 
Information  Assurance 


The  steps  taken  to  protect  our  information  collection,  transfer,  and  storage,  which  constitute 
information  assurance,  can  be  decomposed  into  the  following  areas: 

A.  Protection  of  our  sources  of  Intelligence  -  Infonnation  used  in  military  operations  is 
collected  from  many  sources,  including  passive  and  active  sensors.  The  sensors  usually  ride  on 
platforms,  such  as  aircraft  or  satellites,  controlled  or  directed  from  various  operations  centers. 

The  provide  intelligence  preparation  of  the  battlefield,  intelligence  during  operations,  and 
operational  effectiveness  data.  Sensor  and  platform  protection  are  essential  needs  for  information 
assurance. 

Finally,  much  of  the  information  driving  decisions  in  a  theater  war,  particularly  a  limited  conflict 
is  produced  by  human  agents.  Some  of  these  are  insiders  in  the  enemy  society  or  force,  others 
are  U.  S.  collectors,  such  as  Special  Forces  teams  operating  in  enemy  territory.  In  either  case,  it 
is  incumbent  on  U.  S.  Forces  to  protect  these  sources.  In  some  cases  protection  can  be  in  the 
form  of  distracting  or  confusing  infonnation,  and  in  other  cases  actual  physical  force  may  be 
necessary.  The  Air  Force  should  develop  basic  principles  for  both  forms  of  protection,  at  least 
where  information  operations  or  deployment  of  air  or  space  power  is  concerned.  C2  systems  must 
be  able  to  take  into  account  planning  operations  to  protect  our  intelligence  sources. 

B.  Protection  of  the  links  from  intelligence  sources  into  the  C2  system  -  Communication 
links  to  sensors  are  vital  parts  of  an  information  collection  system.  Control  infonnation  is 
transmitted  to  a  sensor,  be  it  aircraft,  ground  force,  human  agent,  or  satellite,  and  information  is 
transmitted  from  the  sensor  to  the  sensor  data  user.  Frequently,  but  not  always,  information  is 
transmitted  by  wireless  link.  Communication  channels,  wireless,  fiber,  or  other,  must  be 
protected.  There  must  be  methods  of  detecting  and  recognizing  jamming  of  either  the  command 
or  response  links  and  responding  effectively.  Robustness  of  connectivity  (such  as  anti -jam 
capability),  multiple  independent  transmission  paths,  and  ability  to  operate  with  degraded 
connectivity  are  the  most  effective  approaches.  Corruption  of  data  as  the  result  of  enemy 
jamming  or  damaging  of  repeater  amplifiers  or  transmission  systems  is  rather  easy  to  detect  even 
if  repair  is  difficult.  Error  detection  and  correction  methods  can  help  to  keep  track  of  these 
errors.  Monitoring  of  transmission  error  rate  is  a  fundamental  task  for  a  communication  system. 

Intercept  of  information  being  transmitted  is  a  threat  that  can  be  treated  in  several  ways.  The 
classical  method  is  through  encryption,  and  much  development  of  encryption  methods, 
particularly  public  key  methods,  is  underway  in  the  civil,  commercial,  community.  Quantum 
encryption  techniques  that  provide  protection  through  fundamental  physical  principles  are  being 
developed  in  government  and  university  laboratories.  This  method  guards  against  undetected 
replacement  of  data.  These  methods  should  be  studied  by  the  Air  Force. 

Spread  Spectrum  communications  can  be  used  to  make  it  difficult,  or  impossible  to  detect  or 
intercept  the  signal.  This  has  been  used  with  great  benefit  for  agent-in-place  and  Special  Forces 
communication  systems. 

C.  Protection  of  the  links  within  the  C  system’s  network(s)  -  All  C  systems  require 
connectivity  between  their  component  parts.  Shared  data-bases  must  be  connected,  and  user 
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workstations  as  well.  Most  of  these  links  are  carried  terrestrially,  and  increasingly  are  carried 
tunneled  within  publicly  accessible  connectivity  such  as  the  Public  Switched  Telephone  Network 
(PSTN)  or  Internet  trunks.  These  links  must  be  protected  from  Denial  of  Service  (DoS)  attacks 
and  intrusion.  While  NS  A  certified  cryptos  provide  excellent  intrusion  protection  and 
Transmission  Security  (Transec),  other  techniques  such  as  link  robustness,  multiple  redundant 
link  paths,  and  ability  to  operate  with  degraded  connectivity  are  essential  to  operating  during  a 
DoS  attack. 

D.  Protection  of  the  data  that  resides  within  the  system  -  Modern  C2  systems  contain  or 
access  large  data  libraries  and  maintain  a  data-base  containing  a  representation  of  the  battlespace. 
Techniques  to  detect  and  correct  data  corruption,  caused  by  random  errors  or  deliberate 
intrusion,  are  essential  to  infonnation  assurance  in  this  area.  Destruction  of  information  is 
usually  easy  to  detect.  Detection  of  replacement  and  corruption  is  more  difficult.  The  integrity 
of  stored  data  is  primarily  maintained  by  the  storage  device  itself.  Devices  may  be  susceptible  to 
natural  or  artificial  electromagnetic  signals.  Critical  storage  devices  should  be  equipped  with 
detectors  that  will  warn  the  user  if  the  device  experiences  electric  or  magnetic  fields  that  could 
disrupt  data  stored  in  the  device. 

The  most  likely  way  in  which  data  can  be  disrupted  is  through  access  and  replacement  by 
friendly  users.  A  record  of  access  and,  particularly,  modification  of  data  by  authorized  users  and 
applications  should  be  kept.  The  record  can  be  reviewed  periodically  to  determine  if  dangerous 
corruption  may  have  occurred. 

Retrieval  errors  are  similar  to  transmission  errors,  and  the  considerations  for  transmission  errors 
apply.  In  addition,  retrieved  information  is  usually  directed  to  a  predetermined  location. 
Misdirection  is  possible  as  the  result  of  enemy  action,  human  error,  or  computer  equipment 
failure  or  program  bugs.  Misdirection  is  easy  to  detect,  but  real-time  analysis  of  the  reason  for 
misdirection  will  be  very  useful  in  eliminating  the  problem. 

Computer  program  bugs  do  not  always  appear  during  simulation,  exercise,  or  beta  testing  of 
applications.  All  of  those  methods  provide  valuable,  but  somewhat  idealized  situations.  Data 
and  application  interactions  that  are  unanticipated  may  cause  conflicts  and  errors  that  can  even 
be  catastrophic.  Applications  can  be  analyzed  and  tested  for  the  most  common  errors.  Records 
of  errors  and  their  resolutions  should  be  kept.  Detection  and  repair  methods  can  eventually  be 
included  in  compilers  or,  even,  in  the  applications  themselves. 

The  threat  from  knowledgeable  and  treacherous  insiders  can  never  be  completely  eliminated. 
Constant  vigilance  must  be  maintained.  An  unlikely,  but  potentially  catastrophic,  danger  is  from 
malicious  compiler  and  tool  designers.  As  the  Air  Force  becomes  more  dependent  on 
commercial  products,  some,  or  many,  of  these  products  will  be  manufactured  abroad. 

The  operating  system  is  the  heart  of  any  computer.  Access  to  all  the  capabilities  of  the  computer 
and  many  of  those  of  the  network  can  be  gained  through  unrestricted  access  to  the  operating 
system. 

Vulnerability  to  penetration  can  be  through  compromise  of  passwords,  classical  “hacking” 
methods,  or  trap  doors.  Existing  and  new  applications  should  be  scanned  to  make  sure  that 
access  violations  will  not  occur. 
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E.  Protection  of  the  links  the  system  uses  to  command  external  resources  -  The  links  the 
system  uses  to  command  action,  either  of  battle  resources  or  of  intelligence  collectors,  are 
subject  to  the  same  sort  of  attack  as  the  links  from  our  sensors.  They  may  be  protected  using  the 
same  techniques. 

Technologies  being  developed  to  provide  information  assurance  are  summarized  in  the  following 
tables. 


Table  4D-1.  Secure  Networking 


Problem 

Technology 

Description 

Internet  routing  infrastructure  subject 
to  denial  of  service  attacks 

Secure  OSPF  (open  shortest 
path  first)  routing  protocol 

Nimrod  routing  security 

Authentication  added  to  routing 

Internet  naming  and  addressing 
infrastructure  is  vulnerable  to  denial 
of  service  attacks 

Internet  Protocol  (IP)  version  6 
(IPv6,  also  known  as  IPsec) 
prototype 

Secure  Domain  Name  Service 
(DNS)  protocol 

IPv6  encrypts  IP  packets 

Secure  DNS  adds  authentication 
and  authorization  to  DNS 

Network  security  services  are  not 
easily  integrated  into  applications 

Cryptographic  application 
programming  interfaces  (CAPI) 

Simple  public  key  interface 
(SPKI) 

Key  mgmt  interfaces 

These  interfaces  give  programmers 
standard  ways  of  adding  security 
functionality  to  software 

Network  security  services  are  not 
interoperable 

IPsec  key  agreement  protocol 

Secure  Mobile  IP 

Multi-layer  security  negotiation 
protocol 

Mobile  IP  security  protocol 
preserves  user  identity  for  nomadic 
users  traveling  across  different 
networks 

Encrypting  group  communication  and 
managing  membership  changes  not 
scalable  to  large  groups 

Secure  fault-tolerant  group 
communication 

Scalable  algorithms  for  key 
management  and  membership 
revocation,  and  language  for 
specifying  group  communication 
policies 

Traditional  operating  system  security 
inappropriate  for  modern  networked 
environments  with  complex  policies 

Domain-Type  Enforcement 
(DTE) 

Fine-grain  access  control  and  an 
associated  policy  “compiler” 

Adequate  security  available  only  in 
special-purpose  OS’s  with  tiny 
market 

Fluke  operating  system 

Security  is  being  integrated  into 
commercially  viable  next-generation 
OS’s 

Distributed  systems  meeting  more 
than  one  critical  property  are  beyond 
the  state  of  the  art 

Horus  distributed  computing 
system 

Group  communications  system 
supporting  secure,  real-time,  fault- 
tolerance 

Rigid  security  and  firewalls  inhibit 
tightly  coupled  cross-domain 
applications  and  establishment  of 
temporary  security  associations 

Adage  authorization  server 

Sigma  security  middleware 

A  distributed  authorization  server 
and  policy  language 

Propagation  of  access  control 
information  across  enclave 
boundaries 

Appendices  4-5 


Table  4D-2.  Detection  and  Tolerance 


Problem 

Technology 

Description 

Current  intrusion  detection 
techniques  are  limited  to  detecting 
a  small  set  of  well-known  events 

Emerald  intrusion  detection 
system 

Detects  unknown  attack  types  on 
networks 

Current  detection  techniques  do 
not  scale,  and  do  not  support 
automated  response 

—  GRIDS  intrusion  detection 
system 

—  Allows  attacks  to  be  specified 
as  a  graph  across  a  network,  thus 
allowing  detection  of  larger-scale 
attacks 

—  Intrusion  Detection  and 

Isolation  Protocol  (IDIP) 

—  Allows  coordinated  detection 
and  automated  response 

Current  technology  does  not 
support  incident  response,  which 
is  costly  labor-intensive  process 

DERBI  (Diagnosis,  Explanation 
and  Recovery  from  computer 
Break-Ins) 

Tool  to  analyze  a  system  for 
indicators  of  a  possible  intrusion. 
DERBI  explains  to  the  system 
administrator  what  it  found,  what  it 
likely  means,  and  how  to  recover. 

Lack  of  standards  impedes 
adoption  of  even  current 
technology 

Common  Intrusion  Detection 
Framework  (CIDF) 

Establishes  standard  interfaces 
for  event  generators  (sensors) 
and  analysis  engines  (detectors) 

Current  intrusion  detection 
detects  only  attacks  on  isolated 
machines  rather  than  on  the 
network  infrastructure 

JiNao  intrusion  detection  system 

Detects  intruders  in  network 
routers,  switches,  and  network 
management  channels.  Integrated 
with  network  management  and 
has  reconfiguration  capabilities 

Multicast  group  communication 
protocols  vulnerable  to  malicious 
participants 

Secure  Group  and  Secure  Ring 
protocols 

Group  communication  protocols 
that  can  prevent  a  malicious 
processor  from  disrupting  the 
correct  delivery  of  messages  and 
from  denial  of  service  attacks 

Common  programming  errors 
leave  most  systems  vulnerable  to 
buffer  overflow  attacks,  the  most 
common  type  of  attack  on  the 
Internet 

Stackguard  compiler 

Programs  compiled  with 

StackGuard  are  not  vulnerable  to 
buffer  overflow  attacks.  No  source 
code  changes  are  required,  and 
executables  are  binary- 
compatible  with  existing  operating 
systems  and  libraries 
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Table  4D-3.  Wrappers 


Problem 

Technology 

Description 

Commercial  products  introduce 
unreliability  and  security  risks 

Generic  Security  Wrappers 

Wrapper  technology  to  augment 
legacy  &  COTS  components  with 
security  functionality.  Includes  a 
wrapper  specification  language 
and  a  kernel-resident  wrapper 
system.  It  intercepts  system  calls 
to  control  privileged  and  non- 
privileged  programs. 
Demonstrations  include  control  of 
administrative  privileges,  access 
control,  and  encryption 

Integrators  cannot  assemble 
components  and  wrappers  into  a 
trustworthy  whole 

Composable  Replaceable 

Security  Modules 

A  tool  to  build  security  into 
systems  by  assembling  security 
functions  from  a  library  of 
reusable,  plugable  security 
modules,  with  standard 
functionality  and  interfaces 

Evaluation  of 

vulnerability/resistance  of  a 
product  or  system 

Vulnerability  Assessment  Tool 

White-box  security  evaluation  tool 
locates  vulnerable  points  in 
source  code,  using  realistic  attack 
models  and  taxonomies  of  known 
security  flaws 
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Appendix  4E 

Revolution  In  Battlefield  Awareness  Of 
Advanced  Ground  Moving  Target  Radar 

There  is  a  significant  technical  advancement  in  Ground  Moving  Target  Indication  (GMTI)  radar 
for  tactical  and  strategic  Intelligence,  Surveillance  and  Reconnaissance  (ISR)  that  will  provide  a 
major  leap  ahead  in  the  Dominant  Battlespace  Awareness  for  the  battle  commander  required  to 
satisfy  Joint  Vision  2010. 

Rather  than  just  slowly  updated  moving  dots,  advanced  GMTI  radar  systems  will  be  able  to 
provide  high  update  moving  target  detection  and  individual  target  features  thus  providing  much 
higher  quality  information  about  the  nature  and  dynamics  of  thousands  of  moving  targets  over 
large  areas.  This  information  will  include  accurate  geo-registered  target  location;  velocity  of  the 
target;  simultaneous  feature  measurements  of  individual  moving  targets  such  as  size,  high  range 
resolution  (HRR)  profile  (ID),  and  synthetic  aperture  radar  (SAR)  and  Inverse  SAR  (ISAR) 
which  produces  2D  images  of  both  fixed  and  moving  targets.  This  enhanced  information  thus 
provides  a  dynamic  picture  of  vehicle  characteristics,  speed,  where  they  are  coming  from  and 
going  to,  and  the  number  of  vehicles  moving  in  specified  areas.  The  vehicle  features  or 
attributes  coupled  with  high  update  track  data  provides  significant  infonnation  concerning  type 
of  military  unit  convoy  characteristics  such  as:  number,  type  and  mix  of  vehicles;  vehicle  traffic 
and  passing  activities  as  a  function  of  road  type;  mix  of  civilian  vs.  military  traffic;  indications  of 
roadblocks,  bridges  or  other  traffic  constrictions;  associated  helicopter  movement,  congregation 
of  vehicles  at  areas  that  can  be  command  posts  or  logistics/refueling  areas;  traffic  sources  such  as 
known  military  installations;  and  traffic  sinks  or  destinations  that  can  be  associated  with  military 
units  etc. 

GMTI  radar  high  update  detections  coupled  with  high  range  resolution  vehicle  feature 
information  is  significantly  different  from  imagery.  Finding  stationary  enemy  targets  in  large 
areas  with  high  resolution  imagery  can  overwhelm  the  exploitation  task  (20  to  200  Mbits/sec) 
and  requires  large  numbers  of  highly  trained  human  image  analysts  to  exploit.  Automatic  or 
computer  aided  target  recognition  of  SAR  imagery  can  help  cue  the  human  analyst  but  is  not  yet 
an  automatic  process  and  will  always  require  large  processors.  On  the  other  hand,  advanced 
dynamic  GMTI  radar  detections  and  their  associated  high  resolution  target  feature  information  is 
a  fairly  low  data  rate  information  stream  (100’s  Kbits/s  to  a  few  Mbits/s  dependent  on  vehicle 
count)  that  can  be  processed  automatically.  If  processed  into  tracks,  with  associated  target 
recognition  tags,  this  data  becomes  at  least  an  order  of  magnitude  lower  than  even  the  raw  GMTI 
data.  Not  only  is  GMTI  track  data  easier  to  analyze,  the  tracks  lend  themselves  to  further 
automated  track  analyses  such  as: 

•  Multiple  hypothesis  tracking  (position,  time,  velocity  and  direction) 

•  Counting  of  number  of  vehicles  as  a  function  of  areas  or  boundaries 

•  Source  determination  of  target  vehicles  &  their  destination  including  traveled  road/path 

•  History  of  movement  over  time 

•  Target  evidence  and  recognition  feature  accrual  and  comparison  over  time 

This  automatic  analysis  of  moving  target  infonnation  is  significantly  easier  and  faster  than  that 
required  for  the  analysis  of  complex  imagery  by  either  human  or  automatic  image  recognition. 
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As  stated  before  this  is  a  common  experience  of  every  hunter  or  fighter  pilot  which  can  easily 
spot  moving  game  or  aircraft  but  has  difficulty  seeing  stationary  targets  even  when  close. 
Dynamic  GMTI  infonnation  and  tracks  are  inherently  time/geo-registered,  provides  immediate 
indication  and  warning  information  and  correlates  well  with  imagery  and  signals  intelligence 
data  thus  providing  a  Common  Operating  Picture  (COP)  of  the  battlefield.  GMTI  tracks  can 
come  from  simultaneous  multiple  radar  sources  that  can  be  automatically  fused  together  by  new 
techniques  in  computerized  multiple  hypothesis  processes. 

The  new  advanced  GMTI  radars  will  provide  update  rates  that  are  dynamically  adjustable 
depending  on  target  dynamics  (velocity,  acceleration,  on-off  road,  intersecting  roads),  range, 
terrain  visibility,  warfighter  area  of  interest,  location  accuracy  required  and  other  target  track 
filter  needs.  The  enemy  has  a  very  difficult  task  to  hide,  conceal  or  confuse  large  numbers  of 
vehicles  dynamically  moving  in  the  open.  GMTI  by  its  very  nature  provides  a  truth  picture  of 
enemy  movement  and  intention  particularly  if  the  enemy  intent  is  to  engage  in  battle. 

Not  too  long  ago,  military  commanders  thought  of  GMTI  surveillance  radar  of  the  ground  as  a 
snap  shot  picture  of  what  was  moving  at  a  point  in  time.  The  venerable  Army  Mohawk  SLAR 
was  an  example  of  that  type  of  picture  which  was  hardly  dynamic  in  nature  but  gave  a  picture  of 
the  number  of  moving  vehicles  at  a  point  in  time.  In  the  early  1980’s,  technology  progressed  to 
the  point  where  passive  phased  array  GMTI  radars  could  provide  a  wide  area  picture  of  moving 
targets  every  30  to  60  seconds  providing  a  more  dynamic  update  of  target  movement  even  if  it 
was  only  moving  dots  or  blobs. 

These  current  GMTI  radars  do  a  good  job  of  detecting  mass  enemy  movements  and  providing  a 
degree  of  battlefield  awareness.  But,  the  information  lacks  target  recognition  features  and  is 
therefore  a  moving  history  of  dots  or  blobs  with  insufficient  update  rate  for  significant  tracking 
over  large  areas.  The  data  can  be  registered  on  terrain  maps  or  images  with  a  background  of 
apriori  terrain  and  road  database  information.  A  compressed  time  history  of  the  data  shows  a 
human  analyst  enemy  target  movement  portrayed  as  a  strobe  or  smoke  trail  on  the  display  that 
allows  human  operators  to  discern  movement  and  direction  and  learn  to  recognize  characteristics 
of  enemy  motion.  The  radars  are  not  able  to  provide  continuous  GMTI  because  of  insufficient 
power-aperture,  the  need  for  interruptions  to  collect  SAR  imagery  (15-45  sec  depending  on  range 
and  resolution)  as  well  as  blanks  in  data  due  to  aircraft  orbit  turns  (lasting  3-5  min).  Because  of 
these  gaps,  the  lack  of  target  feature  measurements  and  their  slow  update  rates,  these  radars  are 
limited  in  their  ability  to  provide  battlefield  intelligence,  reconnaissance,  battle  damage 
assessment,  or  precise  moving  target  location  capability.  They  are,  however,  very  useful  as 
indications  and  warning,  battle  management  and  command  and  control  systems  for  providing 
battle  commanders  information  on  enemy  motion  and  the  timing  of  events  as  well  as  providing 
coarse  information  for  target  -  weapon  pairing  and  subsequent  target  reacquisition  by  strike 
forces. 

Radar  Technology  Advances 

Technical  GMTI  advances  have  occurred  in  the  past  few  years  that  significantly  changes  the 
capability  to  provide  even  more  useful  dynamic  battlefield  information.  Some  of  the  major 
technical  advances  are: 

•  Active  Electronic  Scanned  Arrays  (AES A)  (ID  or  2D  steering)  use  distributed  low  cost  solid  state 
modules  to  feed  each  radiating  element: 
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•  The  resulting  AESA  is  a  highly  modular  and  scaleable  approach  that  will  allow  significantly 
lower  manufacturing  cost  over  that  of  older  tube  transmitter  designs 

•  Production  MMIC  Transmit  /  Receive  (T/R)  X  band  (8-12  GHz)  modules  typically  come  in  1,  5 
or  10  watt  powers  and  are  projected  to  cost  less  than  $500  per  radiator  site. 

•  T/R  modules  in  close  physical  proximity  to  the  radiating  elements  have  both  high  efficiency  and 
much  lower  losses  thus  providing  high  effective  radiated  powers. 

•  Planar  multi-layer  printed  circuit  board  manifolds  distribute  low  voltage  DC  prime  power,  low 
level  RF  signals  and  digital  control  signals  to  the  active  T/R  modules. 

•  Compact,  distributed,  high  power  solid  state  low  voltage  DC  power  supplies  feed  power  to  the 
T/R  modules. 

•  The  T/R  modules  and  radiating  elements  have  multi-giga  Hertz  tuning  ranges  and  very  wide  band 
instantaneous  bandwidth  capable  of  ultra  high  resolution  waveforms. 

•  The  solid  state  T/R  modules  have  very  high  reliability  and  graceful  degradation  that  can  approach 
the  life  of  the  airframe  carrying  it. 

•  The  continuing  march  of  faster  and  faster  embedded  digital  signal  processors  currently  allows 
greater  than  100  Giga-Operation/second  per  cubic  foot,  with  the  promise  of  Tera-Ops/cubic  foot 
in  the  near  future 

•  Wide  band  frequency  hop/chiip  exciter/receivers  with  capability  for  greater  than  1  GHz 
instantaneous  bandwidth  will  provide  high  resolution  modes  from  0.1  to  1  meters  and  tuning 
ranges  in  excess  of  multiple  GigaHertz. 

•  Active  aperture  radars  allow  simultaneous/interleaved  pulse  to  pulse  modes  (GMTI,  High  Range 
Resolution  (HRR)  and  SAR  Imaging)  with  manageable  performance  degradation  from  operating 
in  these  simultaneous  modes. 

•  Advanced  processing  schemes  for  multi-beam  Space  Time  Adaptive  Processing  (STAP)  allows 
improved  cancellation  of  moving  ground  clutter  as  well  as  adaptive  spatial  nulling  of  jammer  and 
interference  signals. 

•  Automatic  moving  target  tracking  of  large  number  of  targets  using  Multiple  Hypothesis  Tracking 
(MHT)  and  kinetic  and  Kalman  filter  algorithms.  Such  trackers  use  feature  evidence 
accumulation  and  pruning  to  sort  out  targets  from  false  alarms  and  confusing  dense  adjacent 
traffic  even  in  the  presence  of  road  intersections  and  drop  outs. 

•  Automatic  moving  target  feature  recognition  using  High  Range  Resolution  (HRR)  one 
dimensional  range  profiles  of  large  numbers  of  targets  (measured  in  0.1  to  0.2  secs/measurement) 
as  well  as  2D  imaging  using  both  inverse  SAR  techniques  (1-3  secs)  as  well  as  Moving  Target 
Imaging  (MTIm)  SAR  (10-30  secs)  that  is  able  to  image  moving  targets.  The  speed  of  the  HRR 
mode  works  very  well  to  aid  automatic  trackers  to  provide  feature  evidence  to  rapidly  recover 
track  drop  outs  in  dense  traffic  or  confusing  road  situations.  Initial  tests  of  multi-look  HRR  at  1ft 
resolution  has  achieved  target  recognition  in  the  85-95%  range.  HRR  will  also  provides  target 
fingerprinting  to  aid  track  maintenance. 

Summary  of  Modern  Active  ESA  GMTI/SAR  Radar 

The  new  advanced  airborne  GMTI  radar  can  provide  a  significant  source  of  tactical,  theater  and 
even  strategic  intelligence  about  dynamic  enemy  force  movement  thus  providing  revolutionary 
performance  in  battlefield  indications  and  warning,  synoptic  battlespace  awareness, 
target/weapon  pairing  information  and  real  time  wide  area  battle  damage  assessment  unlike  any 
in  the  past: 

•  High  update  rate  track  of  1000’ s  of  individual  vehicles  over  wide  areas  and  at  significant  ranges 
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Target  recognition  that  turns  moving  dots  into  recognized  target  entities 
Automatic  real  time  signal  and  data  processing 

Significant  intelligence  about  enemy  forces  such  as  automatic  sentinels  around  areas,  vehicle 
counts,  sources/sink  detection,  convoy  and  group  detection  and  tracking  data  and  history  of 
movements. 

Interleaved,  simultaneous  GMTI,  SAR  and  target  recognition  modes 

Ultra  high  resolution  SAR  spot  images  with  2-3  times  the  resolution  of  current  fielded  systems 

Advanced  GMTI/SAR  Radar  Modes 
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Figure  4E-1.  Advanced  GMTI/SAR  Radar  Modes 
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Appendix  6C 

The  Current  Air  Force  Acquisition  Process  for  C2  Systems: 
A  Case  Study  ofTBMCS 


Summary 

The  Theater  Battle  Management  Core  Systems  Program  (TBMCS)  is  the  current  Air  Force 
flagship  program  for  automating  and  integrating  the  planning  and  execution  of  the  theater  air 
war.  This  report  provides  a  detailed  developmental  case  history  ofTBMCS  from  the  late  1980s 
through  June  2000.  This  case  study  was  commissioned  by  the  Acquisition  Panel  of  the  US  Air 
Force  Scientific  Advisory  Board  (SAB)  2000  Summer  Study  entitled  “Air  Force  Command  & 
Control — the  Path  Ahead.”  It  is  intended  to  illustrate  how  the  Air  Force  developed  and  procured 
its  most  important  tactical  command  and  control  systems  in  the  1990s.  The  purpose  of  this  case 
study  is  to  help  identify  areas  where  the  Air  Force  can  improve  its  acquisition  strategies  in  the 
future  for  tactical  command  and  control  systems.  The  account  presented  here  is  based  almost 
entirely  on  interviews  with  key  Air  Force  and  industry  participants  in  the  TBMCS  program,  as 
well  as  on  the  extensive  historical  written  documentation  of  the  program  made  available  to  the 
author  by  the  TBMCS  Program  Office  located  at  the  Electronic  Systems  Center,  Hanscom  Air 
Force  Base. 

The  five  core  functions  ofTBMCS  can  be  defined  as  (1)  intelligence  collection  and  evaluation, 
(2)  planning,  (3)  generating  and  distributing  the  Air  Tasking  Order  (ATO),53  (4)  unit  level 
scheduling  of  missions;  and  (5)  monitoring  execution  of  the  ATO.  TBMCS  is  intended  to  link 
these  intelligence,  planning,  and  operations  functions  through  the  integration  of  several  legacy 
systems  (or  their  equivalent  functional  capabilities),  the  most  important  of  which  are  the  Combat 
Intelligence  System  (CIS),  the  Contingency  Theater  Automated  Planning  System  (CTAPS),  and 
the  Wing  Command  and  Control  System  (WCCS).  In  addition,  TBMCS  migrates  these  key 
theater  air  warfare  applications  to  the  Defense  Information  Infrastructure  Common  Operating 
Environment  (DII  COE).54 

TBMCS  has  experienced  a  troubled  and  controversial  history  since  its  fonnal  launch  in  late 
1995,  when  Loral  Command  and  Control  Systems  (LCCS,  now  Lockheed  Martin  Mission 
Systems  [LMMS]  of  Colorado  Springs)  won  a  six-year  competitive  cost  plus  award  fee  (CPAF) 
contract  valued  around  $  180  million.  The  program  has  suffered  from  significant  schedule 
slippage,  some  cost  growth,  and  major  performance  short  falls.55  The  original  concept 


53  The  ATO  is  a  method  used  to  task  and  disseminate  to  components,  subordinate  units,  and  command  and  control 
agencies  projected  sorties/capabilities/forces  to  targets  and  specific  missions.  Normally  it  provides  specific 
instructions  to  include  call  signs,  targets,  controlling  agencies,  etc.,  as  well  as  general  instructions.  (See  the 
Defense  Technical  Information  Center  (DTIC)  DoD  Dictionary  of  Military  Terms). 

54  The  DII  COE  is  DoD’s  common  software  infrastructure,  architecture,  and  set  of  guidelines  and  standards,  which 
will  be  used  for  all  military  C4I  systems,  such  as  the  Global  Command  and  Control  System  (GCCS). 

53  The  original  contract  value  to  the  prime  contractor  was  $35  million  (excluding  fee,  zero  base  fee),  with  options 
that  were  eventually  exercised  amounting  to  $109  million,  resulting  in  a  total  of  $144  million.  Award  fees  and 
miscellaneous  changes  raised  this  to  $179  million.  A  category  labeled  “evolutionary  Requirements  (technical  task 
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envisioned  the  fielding  of  three  progressively  more  capable  software  releases,  with  the  final  V 
3.0  release  available  in  2001.  Early  in  the  program,  release  of  Version  1.0  was  planned  for 
March  1998.  Instead,  as  of  June  2000,  the  program  still  had  not  been  able  to  successfully 
complete  and  field  Version  1.0.  In  addition,  the  Version  1.01  represented  a  significant  down¬ 
scoping  in  the  capabilities  envisioned  earlier  for  the  first  release.36  As  a  result,  many  observers 
have  viewed  TBMCS  as  a  seriously  flawed  program  with  regard  to  its  development  process  and 
other  factors,  at  least  in  the  early  phases. 

As  of  mid  2000,  however,  the  program  generally  appeared  to  be  on  track.  A  detailed  plan  for  the 
fielding  and  future  upgrading  of  the  system  has  been  developed.57  Nonetheless,  its  many 
problems  make  it  worth  examining  carefully  for  “lessons  learned”  for  future  Air  Force 
approaches  for  tactical  C“  systems  acquisition.  It  is  a  story  that  the  Air  Force  should  avoid 
repeating. 

Based  on  this  detailed  case  study,  we  conclude  that  the  problems  experienced  on  TBMCS  were 
caused  primarily  by  the  following  factors: 

Lack  of  sufficiently  detailed  concept  of  operations  (CONOPS),  concept  of  employment 
(CONEMPS),  system  architecture,  and  operational  requirements.  TBMCS  was  launched 
with  a  strong  visionary  high-level  CONOPS  and  system  architecture.  However,  these  lacked  the 
detail  necessary  to  provide  appropriate  guidance  to  the  Air  Force  and  contractor  Program 
Managers  (PMs)  for  development  of  the  system.  No  fonnal  Operational  Requirements 
Document  (ORD)  was  ever  produced.38  The  problem  was  compounded  by  the  lack  of  consensus 
among  the  user  communities  over  CONOPS  and  operational  requirements,  and  by  continual 
change  and  evolution.  The  constant  refrain  of  the  contractor  remained  throughout  the  program: 
“Will  the  real  user  please  stand  up?”59 

Lack  of  consistent,  strong  advocacy  leadership  on  the  highest  levels  of  the  Air  Force,  and  at 
the  SPO  and  contractor  levels,  particularly  during  crucial  points  during  the  program. 

Initially  TBMCS  had  a  few  strong  advocates  on  the  highest  levels  of  the  Air  Force.  This  is 
particularly  true  during  the  very  early  phases  of  the  program  when  John  Gilligan  was  the 
Program  Executive  Officer  (PEO).  Yet  at  one  key  point  during  the  development  phase,  an  Air 
Force  Major,  far  down  in  the  SPO  hierarchy,  acted  as  the  de  facto  PM  for  at  least  six  months 
during  a  crucial  development  period.  The  program  lacked  clear  lines  of  authority  and  strong 
leadership  both  on  the  government  side  and  the  contractor  side.  Perhaps  most  important,  there 
was  no  single  powerful  focal  point  of  responsibility,  advocacy,  and  oversight  for  the  program. 
This  was  particularly  true  in  the  area  of  requirements  development. 

Inappropriate  application  of  current  acquisition  reform  (AR)  doctrines  of  transferring 
greater  system  definition  responsibility  to  the  contractor.  Partly  by  default,  and  partly 


descriptions)”  added  an  additional  $161  million,  for  a  total  contract  value  in  mid  2000  of  $327  million.  Mr.  Steven 
Kent,  ESC,  provided  this  information. 

56  However,  TBMCS  Version  1.01  also  includes  other  capabilities  not  envisioned  in  1995 

57  TBMCS  passed  its  Field  Demonstration  Test  in  June  2000.  A  Multi-Service  Operational  Test  &  Evaluation  took 
place  in  late  July. 

58  CTAPS  and  WCCS  did  have  formal  System  Operational  Requirements  Documents. 

59  Interview  by  author  with  Reese  Delorey,  TBMCS  Lockheed  Program  Manager,  15  April  2000. 
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because  of  DoD  acquisition  reform  doctrine,  program  officials  granted  the  prime  contractor 
significant  control  over  the  development  of  the  system  operational  architecture,  configuration, 
and  even  CONEMPS.  Especially  in  the  early  phases  of  the  program,  the  contractor  senior 
management  lacked  the  operational  knowledge,  technical  skills,  and  initiative  to  meet  this 
challenge  effectively  without  greater  guidance  from  the  Air  Force.  Clear  guidance  was  not 
forthcoming,  because  no  consensus  existed  in  the  Air  Force  on  these  issues. 

Use  of  a  “big  bang”  development  approach  instead  of  a  spiral  approach,  which  delayed 
fielding,  and  resulted  in  operator  pressure  to  divert  resources  to  fixing  legacy  systems.60 

The  TBMCS  contract  called  for  the  development  and  fielding  of  three  major  software  releases 
over  a  six  year  period.  The  user  community  lobbied  hard  for  a  much  quicker  fielding  of  initial 
capabilities.  This  led  to  the  decision  to  divert  significant  resources  to  fixing  existing  fielded 
systems  (CTAPS,  CIS,  WCCS).  This  effort  proved  far  more  difficult  than  anticipated,  leading  to 
significant  delays  in  the  TBMCS  program,  because  the  fielded  legacy  systems  were  seriously 
flawed.  In  theory,  a  spiral  development  approach  could  have  led  to  a  much  earlier  fielding  of 
initial  capabilities,  thus  reducing  the  pressures  to  divert  resources  to  fixing  legacy  systems. 

Insufficient  “jointness”  in  the  original  program  planning  vision.  Failure  to  include  sufficient 
joint  vision  in  initial  program  planning  contributed  to  the  unanticipated  need  to  rehost  CTAPS  to 
Sun  Solaris  and  HP  Unix  servers  for  Navy  shipboard  operations.  This  was  identified  as  a  major 
unplanned  diversion  of  resources.  In  general,  Navy  requirements  and  needs  were  not  sufficiently 
recognized  in  the  early  phases  of  the  program.  The  scale  of  the  Air  Support  Operations  Center 
(ASOC)  upgrade  program  effort  for  the  Army  Corps  level  was  also  underestimated. 

Underestimation  by  both  the  government  and  prime  contractor  of  the  technical  difficulty  of 
integrating  legacy  systems.  Multiple  contractors  had  developed  the  legacy  software  modules 
which  would  go  into  TBMCS,  usually  in  conjunction  with  a  specific  government  laboratory  and 
a  specific  user  command.  Thus  the  pieces  that  would  make  up  TBMCS  had  no  uniformity  in 
architecture,  computer  language,  etc.  Little  formal  documentation  existed,  resulting  in 
difficulties  in  transferring  the  necessary  legacy  information  to  Lockheed.  This  problem  was 
exacerbated  by  third  party  “associate”  contractors  which  had  no  formal  contractual  relationship 
with  Lockheed.  Finally,  some  particularly  troublesome  modules,  such  as  FLEX,  were  developed 
by  labs  as  technology  demonstrations,  and  were  not  appropriate  for  fielding.  In  the  case  of 
FLEX,  neither  the  SPO  nor  Lockheed  had  direct  control  over  development.  Finally,  virtually  all 
the  legacy  modules  were  more  immature  technically  than  originally  anticipated.  One  TBMCS 


60  Spiral  Development  is  a  developmental  process  commonly  used  in  the  commercial  software  world  for  incremental 
development  and  rapid  fielding  of  new  capabilities.  It  is  based  on  iterative,  short  development  cycles  that  focus  on 
risk  areas,  and  which  integrate  users,  developers,  acquirers,  and  testers.  Air  Force  Instruction  63-123  Evolutionary’ 
Acquisition  for  C2  Systems,  1  June  2000,  provides  a  guide  for  mandatory  use  of  the  spiral  development  process  in 
Air  Force  C2  development  programs.  Some  authorities  believe  this  document  does  not  adequately  describe  the 
process  of  spiral  development  as  used  in  the  commercial  world.  For  one  discussion  of  the  concept,  and  the  problems 
of  implementing  it  in  military  C2  acquisition  programs,  see  the  briefing  WG4  Institutional  Challenges,  prepared  by 
members  of  the  Spiral  Workshop,  February  2000,  sponsored  by  the  Carnegie  Mellon  Software  Engineering  Institute, 
and  the  Center  for  Software  Engineering,  University  of  Southern  California. 
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Program  Manager  summed  up  this  issue  by  noting:  “the  biggest  failure  of  TBMCS  has  been 
setting  unrealistic  levels  of  expectations.”61 

Inadequate  process  for  controlling  and  screening  requirements  and  capabilities 
development  and  additions.  The  user  community  continued  to  develop  independently  new 
modules  and  capabilities  that  were  progressively  folded  into  the  program.  No  process  existed  to 
assess,  prioritize,  and  filter  these,  leading  to  much  added  integration  work  for  the  prime 
contractor.  Little  discipline  was  exercised  over  requirements  growth  and  change  by  either  the 
government  or  the  prime  contractor,  since  no  clear  baseline  configuration  was  ever  established 
early  in  the  program. 

Lack  of  an  appropriate  strategy  for  testing  and  fielding  the  system.  The  program  did  not 
develop  a  consensus  on  a  unified  testing  concept  and  approach,  nor  on  test  metrics  forjudging 
success.  A  lack  of  a  unified  and  detailed  CONOPS  and  CONEMPS  resulted  in  the  lack  of  a 
standard  use  pattern  by  users.  Different  testers,  with  different  use  patterns,  and  using  different 
test  metrics,  conducted  the  various  operational  and  fielding  tests,  producing  widely  varying 
results. 


The  following  section,  a  case  study  of  the  development  of  TBMCS,  has  not  been  cleared  for 
public  release.  In  the  event  you  have  a  need  to  obtain  this  information,  please  contact  the 
Executive  Director  of  the  U.S.  Air  Force  Scientific  Advisory  Board  at  (703)-697-4811. 


61  Note  to  author  from  Carl  Steiling,  18  August  2000. 
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Acronyms 


AADC 

ACC 

ACC/DR 

ACPT 

AFMC 

AFMSS 

AFOTEC 

AFSC 

ALC 

AMC 

AOC 

APS 

AR 

ASOC 

ASP 

ATO 

BSD 

C2IPS 

C3 

CAF  C2  SPO 

CAFMS 

CAOC 

CCB 

CIS 

CMM 

COP 

COTS 

CPAF 

CTAPS 

CTIS 

DE 

DIA 

DII  COE 

DISA 

DR 

DRs 

ECP 

EOB 

ESC 

Evms 

Fdt&E 

FFRDC 

FLEX 

FYDP 

GCCS 

GOSG 

GTACS 

GTN 


Area  Air  Defense  Commander 
US  Air  Force  Air  Combat  Command 
Deputy  Chief  of  Staff  for  Requirements,  Air  Combat 
Command 

Air  Campaign  Planning  Tool 

Air  Force  Materiel  Command 

Air  Force  Mission  Support  System 

Air  Force  Operational  Test  and  Evaluation  Center 

Air  Force  Systems  Command 

Air  Logistics  Center 

US  Air  Force  Air  Mobility  Command 

Air  Operations  Center 

Advanced  Planning  System 

Acquisition  reform 

Air  Support  Operations  Center 

Acquisition  Strategy  Panel 

Air  Tasking  Order 

Battlefield  Situation  Display 

Command  and  Control  Information  Processing  System 
Command,  control  and  communication  programs 
Combat  Air  Forces  Command  and  Control  System  Program 
Office 

Computerized  Assisted  Force  Management  System 
Combined  Air  Operations  Center 
Configuration  Control  Board 
Combat  Intelligence  System 
Capability  Maturity  Level 
Common  operational  picture 
Commercial-Off-the-Shelf 
Cost  Plus  Award  Fee 

Contingency  Theater  Automated  Planning  System 
Command  Tactical  Information  System 
Domain  Engineering 
Defense  Intelligence  Agency 

Defense  Information  Infrastructure  Common  Operating 
Environment 

Defense  Information  Systems  Agency 

Directorate  of  Requirements 

Deficiency  Reports 

Engineering  Change  Proposal 

Enemy  order  of  battle 

Electronic  Systems  Center 

Earned  Value  Management  System 

Final  Development  Test  and  Evaluation 

Federally  funded  research  and  development  center 

Force  Level  Execution 

Five-Year  Defense  Plan 

Global  Command  and  Control  System 

General  Officer  Steering  Group 

Ground  Theater  Air  Control  System 

Global  Transportation  Network 
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ICM 

IDE 

1NEL 

INRI 

JAT 

JFACC 

JFAT 

JMCIS 

KLFs 

LCCS 

LMMS 

MAJCOMS 

MAOC 

MCFs 

MENS 

MIDB 

MOT&E 

NAFs 

O&M 

OB 

ORD 

OTAS 

PACAF 

PE 

PEO 

PM 

PMR 

Pri 

R/SAOC 

RAAP 

RFP 

SAB 

SAIC 

SLOCs 

SON 

SOR 

SPAWAR 

SSEB 

STRATCOM 

SWPS 

T/DRs 

TAG 

TAP 

TBM 

TBMCS 

TSPR 

TTDs 

WCCS 


Intelligence  Correlation  Module 
ln-process  Design  Evaluation 
Idaho  National  Engineering  Laboratories 
Inter-National  Research  Institute  Inc. 

Joint  Acceptance  Test 

Joint  Force  Air  Component  Commander 

Joint  Fielding  Acceptance  Test 

Joint  Maritime  Command  Information  System 

Key  legacy  functions 

Loral  Command  and  Control  Systems 

Lockheed  Martin  Mission  Systems 

Major  Commands 

Modular  Air  Operations  Center 

Mission  critical  functions 

Mission  Needs  Statements 

Military  Integrated  Data  Base 

Multi-Service  Operational  Test  &  Evaluation 

Numbered  Air  Forces 

Operations  and  Maintenance 

Order  of  Battle 

Operational  Requirements  Document 
Operational  Test  Assessments 
Pacific  Air  Forces 
Program  Element 
Program  Executive  Officer 
Program  Manager 
Performance  Metrics  Reporting 
Priority 

Regional/Sector  Air  Operations  Center  Modernization 
Program 

Rapid  Application  of  Air  Power 

Request  for  Proposal 

US  Air  Force  Scientific  Advisory  Board 

Science  Applications  International  Corporation 

Single  Lines  of  Code 

Statement  of  Need 

System  Operational  Requirements  Documents 

US  Navy  Space  and  Naval  Warfare  Systems  Command 

Source  Selection  Evaluation  Board 

Strategic  Command 

Strategic  Warfare  Planning  System 

Test  Discrepancy  Reports 

Tactical  Air  Command 

THEATER  AIR  PLANNING 

Theater  Battle  Management 

Theater  Battle  Management  Core  Systems  Program 

Total  System  Performance  Responsibility 

Technical  Task  Descriptions 

Wing  Command  and  Control  System 
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Appendix  6D 

GCCS  Integration  Process 


GCCS  Integration  Process 


Microsoft  Model 

Configuration  Managed 
Operating  System  (Windows  2000) 

Tightly  Integrated 
Killer  Applications  (Power  Point) 
Partner  Developed 
Applications  (Quicken) 

Windows 


-  MARKET  SHARE 


GCCS  Model 

Configuration  Managed 
Operating  System  (COE  Kernel) 

Tightly  Integrated 
Killer  Applications  (COP) 
Partner  Developed 
Applications  (13*,  METOC) 


-  INTEROPERABILITY  - 
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Appendix  6E 

GCCS  Mission  Applications  Schedules 


Mission  Applications  Schedule 


1998 

1999 

2000 

2001 

J 

F 

M 

A 

M 

j 

J 

A 

s 

O 

N 

D 
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F 

M 

A 

M 

J 

J 

A 

S 

O 

N 

D 

Community 

Executive 

Agent 

Office  Automation 

OPS 

NetMeeting 

DISA/NCI 

r 

OPS 

PCXware 

DISA/NCI 

▲  t 

OPS 

Seagate  Backup 

□SA/COTS 

At 

A 

S 

OPS 

Office97  (Office  2  0  00) 

DISA/MS 

At 

A 

s 

A 

OPS 

Defense  Message  System  Automated  Message 
Handling  System  (DMS  AMHS)  Message  Manager  (MM) 

DISA 

OPS 

Remote  Dial  (AT&T  STU  III) 

DISA/AT&T 

At 

u 

OPS 

Secret  Agent 

DISA/AT&T 

i^T 

[s 

OPS 

Front  Page 

DISA/MS 

At 

Cs 

OPS 

Defense  Message  System  Automated  Message 
Handling  System  (DMS  AMHS)  Outlook -T 

DISA 

£ 

T 

Force  Planninq 

OPS 

OPS 

JOPES  Editing  Tod  (JET) 

Rapid  Query  Tool  (RQT) 

DISA 

DISA 

A 

A 

A 

A 

A 

A 

A 

A 

J2K 

J2K 

INTEL 

Gobal  Reconnaissance  Information  System  Web 
Interface  (GRISWI) 

DISA 

A 

OPS 

Common  Operational  Modeling  Planning  and 
Simulation  Strategy  (COMPASS) 

JPO 

A 

A 

1 

LOG 

Joint  Forces  Requirements  Generator  (JFRGI) 

USMC 

A 

OPS 

Nickname,  Codeword  and  B(erciseTerm  (MCKA) 

DISA 

OPS 

Force  Mod  lie  Editor  (FMEDIT) 

JPO 

r 

A 

OPS 

Theater  Analysis  and  Replanning  Graphical  Execution 
Tookit  (TARGET) 

JPO 

A 

OPS 

Adaptive  Coirses  of  Action  (ACOA) 

JPO 

A 

A 

A 

A 

OPS 

Nuclear  Weapons  Contingency  Operational  Modde 
Server  (NWCOMS) 

DTRA 

A 
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Mission  Applications  Schedule 

(continued) 


1998 

1999 

2000 

2001 

J 

F 

M 

A 

M 

J 

J 

A 

S 

O 

N 

D 

J 
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M 

A 

M 
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J 

A 

S 

O 

N 

D 

Community 

Executive 

Agent 

Readiness  Assessment 

OPS 

Gobal  Status  of  Resources  and  Training  System 
(GSORTS)-lnput  Tool 

DISA 

▲ 

OPS 

Gobal  Status  of  Resources  and  Training  System 
(GSORTS)-Output  Tool 

DISA 

▲ 

A 

V4.0 

OPS 

Automated  Joint  Monthly  Readiness  Report  (AJ  MRR) 

JPO 

A 

Situational  Awareness 

USAF 

Air  Force  Option  4  (AF04) 

USAF 

A 

LOG 

Medical  Analysis  Tool  (MAT) 

Army 

A 

LOG 

Gobal  Combat  Support  System  (GCSS)  COP-CSE  * 

DISA 

A 

A 

Common 

METOC  System  (JMS)/METOC  Imagery  System  (MIS) 

USN 

A 

OPS 

Information  Dissemination  Management  (IDM) 

JPO 

A 

R2 

z 

i  R3.1 

OPS 

COP  Embedded  Training 

DISA 

- 

Common 

Meteorological  and  Oceanographic  Tactical  Forecast 
System  (METOC  TFS) 

USAF 

- 

INTEL 

Integrated  Intelligence  and  Imagery  (13) 

USN 

A 

OPS 

Joint  Defense  Planner  (JDP) 

USAF 

A 

V-Version  S-GCCSSecret  T  -  GCCS  Top  Secret  *- Limited  Distribution  Current  Projected  Fielding  A  -  Actual  Fielding 
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Appendix  6F 

GCCS  Mission  Applications  Abstracts 


Fielded 

Coming 

Air  Force  Option  4 

•  ACOA 

COMPASS  NT 

•  AJMRR 

COP  Embedded  Training 

•  AMHS  MM 

Front  Page  (T)(S) 

•  COMPASS 

GCSS  COP-CSE 

•  DMS-T  (T) 

GRISWI 

•  FMEDIT 

GSORTS  (E)  Input/Output 

•  GCSS 

JET  (T)(S) 

•  13 

MAT 

•  IDM 

METOC  JMS/MIS 

•  JDP 

METOC  TFS 

•  JFRG II 

NetMeeting  (T) 

•  NICKA  (T) 

Office97  (T)(S) 

•  NWCOMS  (T) 

PC-Xware  (T) 

•  Secret  Agent(S) 

Remote  Dial-In  (T) 

•  TARGET 

RQT  (T)(S) 

Seagate  Backup  (T)(S) 

Secret  Agent  (T) 

The  abstracts  are  located  on  the  following  pages  and  on  the  SIPRNet  at: 
http://cficms.osf.disa.smil.mil:  1 1 10/aug_home/gccs301/stage2/abstracts/stage2_abstracts.html 
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Air  Force  Option  4 


1.  System  Description 

Air  Force  Option  4  (AFOPT4)  provides  GCCS  3.0.1  a  direct  interface  to  CTAPS,  ATO/ACO 
query  capabilities,  and  graphic  and  tabular  displays  of  ATO/ACO  data.  AFOPT4  is  comprised 
of  three  segments,  GARDP,  CAFMS-X(G),  and  Task  View: 

GARDP:  The  GCCS  Air  Tasking  Order  (ATO)  Review  and  Dissemination  Package 

(ARDP)  and  ATO  Airspace  Control  Order  (ACO)  Tool  (AAT),  provides  file  management  and 
viewing  capabilities  of  ATO/ACOs.  It  accesses  the  CTAPS  thru  SMTP  mail  to  pull  the  entire 
ATO. 

CAFMS-X:  The  Computer-Assisted  Force  Management  System  provides  GCCS  users  read¬ 
only  access,  using  X-Windows,  to  the  Contingency  Theater  Automated  Planning  System 
(CTAPS)  via  a  connected  Air  Operations  Center.  It  accesses  the  CTAPS  via  SQLNET  queries. 

Task  View:  The  Air  Force  Mission  Planning  Systems  (AFMPS)  ATO  Task  View  provides 
access  to  USMTF  ATO/ACO  data  to  query  and  to  display  non-COP,  multiple  graphical  views  of 
message  components. 

AFOPT4  tools  provide  an  interim  capability  for  ATO/ACO  access  and  viewing  until  the  fielding 
of  Theatre  Battle  Management  Core  System  (TBMCS).  TBMCS,  a  Joint  Staff  program  with  Air 
Force  as  Executive  Agent,  is  a  DII  COE  compliant,  joint  air  operations  planning  and  execution 
application.  It  replaces  non-Y2K  CTAPS  with  a  new,  Y2K  compliant  ATO/ACO  tool,  which 
uses  the  joint  standard  USMTF  98.  Therefore,  it  should  be  noted  that  GARDP  and  CAFMS-X 
segments  will  not  be  able  to  function  after  TBMCS  is  fielded,  as  they  are  dependent  on  CTAPS. 
Task  View  can  partially  function,  since  it  uses  an  enhanced  message  fonnat,  USMTF  95-3. 
NOTE:  a  GCCS-TBMCS  interface  is  required  to  use  Task  View.  As  of  first  quarter  FY99,  no 
interfaces  have  been  scheduled  for  GCCS  3.0.1. 

2.  System  Requirements 

All  segments  of  the  AFOPT  4  application  reside  on  the  Solaris  Platform.  CAFMS-X  depends  on 
Oracle  Client  Applications  and  Netscape  Web  Browser.  Task  View  and  GARDP  have  no 
external  software  requirements 

3.  Users/Training 

AFOPT4  was  created  to  provide  an  alternative  for  GCCS  users  who  receive  ATO  information 
via  floppy  disk  or  FTP.  Training  for  AFOPT4  is  developed  by  the  Air  Force  and  consists  of 
interactive  web-based  functionality  and  downloading  of  training  programs  from  the  Air  Force 
Web  Page.  Because  of  its  limited  timeline  usage,  AFOPT  4  training  will  be  completed  at  the 
journeyman  level  only. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj  Cooper  (703)  735-8611. 

The  GCCS  Engineer  POC  is  Cindy  Hopkins  (703)  735-8754. 
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COMPASS  NT 


1.  System  Description 

COMPASS  is  a  set  of  Government  Off-The-Shelf  (GOTS)  and  Commercial  Off-The-Shelf 
(COTS)  software  services.  COMPASS  provides  a  non-intrusive  middleware  approach  that 
facilitates  Collaborative  Planning,  Modeling  &  Simulation  (CPM&S)  access  as  well  as 
Distributed  Collaborative  Planning  (DCP)  to  the  Joint-Combined  Arms  environment. 

COMPASS  allows  planners  using  disparate  mission  planning  systems  to  move  between  local 
planning,  collaborative  planning,  analysis,  and  simulation-based  rehearsal  modes.  COMPASS 
capabilities  include  a  client-server  architecture  with  session  management  (SMGT)  tools,  a  shared 
overlay  manager  (SOM),  a  composite  route  preview  (CRP)  capability,  COTS  DCP  tools,  GOTS 
DCP  server  tools,  and  the  ability  to  observe  external  M&S  products  on  host  C4I  and  mission 
planning  systems. 


COMPS  (SOL,  NT) 

[GOTS] 

The  COMPASS  server  segment  is  a  set  of  four  tightly  integrated  servers:  Session 
Management  (SMGT),  Shared  Overlay  Management  (SOM),  Composite  Route 

Preview  (CRP),  and  Track/Simulation  Management  (TSM).  Each  of  the  COMPASS 
servers  has  a  companion  client  library  that  is  integrated  within  a  modeling,  planning,  or 
simulation  client  application  (e.g.,  GCCS,  CTAPS,  AFMSS,  and  ModSAF).  These 
client  libraries  process  remote  procedure  calls  from  the  client  application  to  their 
companion  server  in  order  to  exchange  modeling,  planning,  and  simulation  data  with 
other  client  applications  via  the  COMPASS  server.  COMPS  also  provide  two 
applications:  Server  Control  (for  starting  and  monitoring  COMPASS  sessions)  and 

Test  Client  (for  developmental  testing  or  COMPASS  session  monitoring). 

COMPC  (HP,  SOL,  NT) 
[GOTS] 

The  COMPASS  client  library  segment  is  a  set  of  four  statically  or  dynamically  linkable 
function  libraries  (SMGT,  SOM,  CRP,  and  TSM).  These  libraries  are  code-integrated 
within  a  COMPASS  client  application  and  process  remote  procedure  calls  from  the 
client  application  to  their  companion  COMPASS  server  in  order  to  exchange  modeling, 
planning,  and  simulation  data  with  other  COMPASS  client  applications. 

GCPA  (HP,  SOL) 

[GOTS] 

The  GCCS  Collaborative  Planning  Application  (GCPA)  is  a  Dll  COE  compliant 
application  that  uses  the  COMPASS  Client  Libraries  (COMPC)  to  exchange  planning, 
modeling,  and  simulation  information  with  other  COMPASS-capable  systems  via  the 
COMPASS  servers  (COMPS).  GCPA  uses  the  Dll  COE  Joint  Mapping  Tool  Kit 
(JMTK),  the  Track  DataBase  Manager  (TDBM),  and  the  UB  communications 
infrastructure  to  interface  with  the  underlying  GCCS  system.  Every  message  received 
from  the  COMPASS  servers  by  the  GCPA  is  processed  and  represented  in  some  way 
to  the  user  of  the  GCPA,  either  on  the  GCPA  GUI  or  the  GCCS  system  chart.  GCPA 
also  has  menu  options  to  launch  multimedia  applications  such  as  audio,  video,  chat, 
and  whiteboard. 

GCPA  Patch  1  HP,  SOL) 
[GOTS] 

GCPA  Patch  1  modifies  the  GCCS  Account  Group  segment  (after  installation  of  the 
CVWC  segment)  to  enable  launch  of  the  CVWC  application  from  the  main  menu. 

CVWC  (HP,  SOL) 

[Public  Domain ,  licensed  by 
Mitre] 

Version 

The  Collaborative  Virtual  Workspace  (CVW)  client  segment  provides  an  intuitive 
method  for  the  COMPASS  user  to  enter  and  leave  COMPASS  sessions.  CVWC 
automatically  launches  and  terminates  COMPASS  applications  to  reduce  workstation 
user  workload  in  a  distributed  collaborative  planning  environment.  See  also  SD,  an 
alternate  method  for  launching  VAT  and  VIC/NV. 

CVWC  Patch  1  (HP,  SOL) 
[Public  Domain ,  licensed  by 
Mitre] 

CVWC  Patch  1  modifies  CVWC  to  enable  launch  and  termination  of  GCPA  and  RWC 
as  COMPASS  sessions  are  entered  or  left  by  the  workstation  user.  Unpatched  CVWC 
launches  and  terminates  only  VAT  and  VIC. 
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CVWS  (SOL) 

[Public  Domain ,  licensed  by 
Mitre] 

Version 

The  Collaborative  Virtual  Workspace  (CVW)  server  segment  provides  a  central 
administrative  facility  for  setting  up  virtual  conference  centers  and  their  subordinate 
sessions.  Virtual  conference  centers  and  their  sessions  are  accessed  by  CVWC. 

RWS  (SOL,  NT) 

[COTS,  licensed  by 

VisualTek  Solutions ,  Inc] 

The  Rendezvous  Whiteboard  server  segment  is  the  server  component  of  an 
Internet/Intranet  Whiteboard.  RWS  allows  simultaneous  text  sessions,  drawing  on  a 
shared  canvas,  file  and  document  sharing,  and  screen  and  image  sharing  and 
annotation.  Rendezvous  provides  server  “channels,”  allowing  large  workgroups  to 
share  information  simultaneously.  Rendezvous  implements  GroupWare  technologies 
such  as  shared  whiteboards,  shared  documents,  text  communication  rooms,  collective 
browsing  in  a  consistent  work  environment.  Rendezvous  is  compatible  with  TCP/IP 
based  networks. 

RWC  (HP,  SOL,  NT) 

[COTS,  licensed  by 

VisualTek  Solutions,  Inc] 

The  Rendezvous  Whiteboard  client  segment  is  the  client  component  of  an 
Internet/Intranet  Whiteboard.  See  RWS  for  additional  details. 

SD  (HP,  SOL,  NT) 

[Public  Domain,  no 
licensing] 

Session  Directory  is  a  multicast  backbone  (MBONE)  application  that  provides  (1)  an 
easy  way  to  create  multicast  sessions,  (2)  a  facility  to  advertise  new  session(s)  and  (3) 
a  dynamically  updated  list  of  available  sessions  (e.g.,  VAT  audio  conferences,  and  NV 
or  VIC  videoconferences).  SD  is  used  in  COMPASS  98  as  an  alternate  method  for 
setting  up  and  launching  audio  (VAT)  and  videoconferences  (VIC/NV). 

VAT  (HP,  SOL,  NT) 

[Public  Domain,  no 
licensing] 

Visual  Audio  Tool  allows  users  to  conduct  host-to-host  or  multihost  audio 
teleconferences  over  an  Internet  (multihost  conferences  require  that  the  kernel  support 
IP  multicast).  On  most  architectures,  no  hardware  other  than  a  microphone  is  required 
-  sound  I/O  is  via  the  built-in  audio  hardware. 

VIC  (HP,  SOL,  NT) 

[Public  Domain,  no 
licensing] 

Primary  video  conferencing  application  for  COMPASS  98.  Video  Conferencing  (VIC) 
was  designed  with  a  flexible  and  extensible  architecture  to  support  heterogeneous 
environments  and  configurations.  For  example,  in  high  bandwidth  settings,  multi¬ 
megabit  full-motion  JPEG  streams  can  be  sourced  using  hardware  assisted 
compression,  while  over  lower  bandwidth  environments  like  the  Internet,  aggressive 
low  bit-rate  coding  can  be  carried  out  in  software.  VIC  is  based  on  version  2  of  the 
Real-time  Transport  Protocol  (RTP),  which  provides  basic  real-time  media 
communication  support.  RTP  is  an  application-level  protocol  and  is  implemented 
entirely  within  VIC  -  no  special  system  enhancements  needed  to  run  RTP.  Although 
VIC  can  be  run  point-to-point  using  standard  unicast  IP  addresses,  it  is  primarily 
intended  as  a  multiparty  conferencing  application. 

NV  (Sun) 

[Public  Domain,  no 
licensing] 

Alternate  video  conferencing  application  for  COMPASS  98.  Network  Video  allows 
users  to  transmit  and  receive  slow  frame  rate  video  via  UDP/IP  across  an  Internet. 

Video  streams  can  be  either  sent  point  to  point,  or  sent  to  several  destinations 
simultaneously  using  IP  multicast.  Receivers  need  no  special  hardware  -  just  an  X 
display.  Transmitters  need  some  sort  of  frame  capture  hardware  (e.g.,  Sun  Video 

Card  part  number  XI 085A) 

NVAT  (NT) 

[Public  Domain,  no 
licensing] 

Alternate  video  conferencing  application  for  COMPASS  98.  Network  Video  Audio  Tool 
(NVAT)  is  an  audio/video  application  for  Windows  95  and  Windows  NT,  compatible 
with  NV  and  VAT.  Uses  RTPvl. 

2.  System  Requirements 

COMPASS  has  Solaris,  HP  and  NT  segments.  Its  additional  hardware  requirements  are  as 
follows: 

•  Video  Card  (e.g.,  Sun  Part  #  X1085A)  for  video  transmission  using  Video  Conferencing  (VIC) 
[not  required  for  video  reception] 
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•  NTSC  Video  Camera  for  video  transmission  using  Video  Conferencing  (VIC)  [not  required  for 
video  reception] 

•  Microphone  for  audio  transmission  using  Visual  Audio  Tool  (VAT) 

3.  Users/Training 

Collaborative  planners  use  the  COMPASS  application. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj.  Cooper  (703)  735-8611. 

The  GCCS  Engineer  POC  is  LCDR  Otis,  (703)  735-8764. 
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Common  Operational  Picture  (COP)  Embedded  Training 


1.  System  Description 

The  Common  Operational  Picture  (COP)  embedded  training  consists  of  three  segments  designed 
to  assist  GCCS  users  in  training,  generating  scenarios  and  recreating  previous  tactical  events.  A 
short  description  of  the  functionality  for  the  three  segments  follows: 

The  Training  (TRAIN)  segment  is  capable  of  creating  and  conducting  a  broad  range  of  training, 
from  simple  entry  level  sessions  to  dynamic,  scenario-driven  operations.  It  is  fully  embedded 
within  GCCS.  All  GCCS  functions  are  available  and  may  be  activated  during  session  creation 
and  playback. 

The  Scenario  Generator  (SCGEN)  allows  a  user  to  position  simulated  platforms  on  the  GCCS 
map,  generate  movement  of  these  platforms,  annotate  events  and  save  the  resulting  track  data  in 
OTH-T  GOLD  replay  files.  These  files  can  be  replayed  with  the  Replay  option,  or  with  the 
Reconstruction  and  Training  modules.  It  is  used  for  creating  scenarios  as  part  of  GCCS 
embedded  training  sessions  and  plans,  and  for  setting  up  dispositions  for  planning,  real 
operations,  live  exercises  and  “what  if’  analysis. 

The  Reconstruction  (RECON)  segment  archives  data  from  the  GCCS  Tactical  Data  Base 
Manager  (TDBM)  and  Communications  Manager.  It  enables  the  operator  to  recreate  past  tactical 
events  on  an  operational  GCCS  system  and  apply  tactical  decision  aides  to  this  non-real  time 
track  data. 

2.  System  Requirements 

COP  Embedded  Training  runs  on  the  SUN/Solaris  2.5.1  platfonn. 

3.  Users/Training 

COP  embedded  training  is  for  all  GCCS  users.  A  subject  matter  expert  can  quickly  and  easily 
build  training  sessions  of  varying  complexity  without  any  knowledge  of  software  development 
techniques,  then  present  them  as  an  overlay  on  the  standard  GCCS  display. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Cindy  Hopkins,  (703)  735-8754. 
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Microsoft  Front  Page 


1.  System  Description 

Microsoft  Front  Page  is  a  web  site  creation  and  management  tool.  It  provides  a  fast  and  effective 
way  to  create  and  manage  professional  quality  Internet  or  Intranet  sites  without  programming.  It 
makes  it  easy  for  new  users  and  professional  Web  developers  to  build  and  maintain  great- looking 
Web  sites  quickly.  Front  Page  is  a  partial  segment  whose  purpose  is  to  validate  that  the 
commercial-off-the-shelf  (COTS)  application,  Microsoft  FrontPage  98,  has  been  installed  on  the 
PC.  The  COTS  product  is  installed  using  the  licensed  CD-ROM  purchased  by  the  site.  This 
version  adds  the  Integ  directory  (containing  the  IntegNotes  and  VSOutput  files)  and  changes  the 
$MEMORY  value  to  18  to  reflect  the  value  stated  in  the  SVD.  Microsoft  FrontPage  98 

2.  System  Requirements 

Front  Page  runs  on  the  Windows  NT  4.0  operating  system.  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  Front  Page  98,  be  installed  on  the  target  computer 
before  the  segment  is  installed.  It  the  COTS  software  is  not  installed,  the  installation  will  be 
tenninated.  Individual  services  or  GCCS  sites  are  required  to  procure  licensed  copies  of  the 
Front  Page  software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764. 
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GCSS  Common  Operational  Picture  (COP)-Combat  Support  Enabled  (CSE) 


1.  System  Description 

The  GCSS  Common  Operational  Picture  (COP)-Combat  Support  Enabled  (CSE)  is  an  extension 
to  the  GCCS  Common  Operational  Picture  that  provides  access  to  combat  support  infonnation. 
This  provides  the  warfighter  a  fused  tactical  and  combat  support  picture  utilizing  one  command 
and  control  application.  The  GCSS  COP-CSE  makes  use  of  the  GCSS  Combat  Support  Data 
Environment  (CSDE)  to  access  multiple  combat  support  data  sources.  The  GCSS  CSDE  consists 
of  a  virtual  database  and  the  GCSS  Data  Model.  Currently,  the  GCSS  COP-CSE  via  the  CSDE 
accesses  combat  support  infonnation  from  the  Joint  Total  Asset  Visibility  (JTAV),  Joint 
Operations  Planning  and  Execution  System  (JOPES),  GCCS  Status  of  Operational  Readiness  and 
Training  Systems  (GSORTS),  Global  Transportation  Network  (GTN)  and  National  Imagery  and 
Mapping  Agency  (NIMA)  databases.  Additional  combat  support  sources  will  be  available  to 
users  of  the  GCSS  COP-CSE  as  they  as  added  to  GCSS  CSDE  in  the  future. 

2.  System  Requirements 

The  GCSS  COP-CSE  runs  on  a  GCCS  3.0.3  Solaris  platform.  Additionally,  the  SUNJRE  1.0.0. 1 
segment  is  required. 

Hardware  requirements:  SUN  workstation  SPARC  20  or  higher. 

Additionally,  the  GCSS  COP-CSE  must  have  SIPRnet  access  to  the  GCSS  Data  Brokering 
Environment  and  users  of  the  GCSS  COP-CSE  must  be  registered  GCSS  users. 

3.  Users/Training 

Training  materials  for  the  GCSS  COP-CSE  are  under  development  by  DISA.  Initial  training  in 
the  PACOM  Theater  will  be  conducted  by  DISA  as  the  segments  are  fielded. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  LTC  Merrick,  (703)  735-8783. 


Appendices  6-20 


GRIS  Web  Interface  (GRISWI) 


1.  System  Description 

The  GRIS  Web  Interface  (GRISWI)  is  a  Joint  Mission  Application  Software  (JMAS)  segment. 

It  is  used  by  the  Joint  Reconnaissance  Centers  (JRCs)  at  designated  Unified  Command  sites. 
GRISWI  provides  automated  support  in  planning,  scheduling,  reporting,  and  monitoring 
reconnaissance  activities  under  the  Sensitive  Reconnaissance  Operations  (SRO)  program. 
GRISWI  maintains  a  near  real-time  status  of  all  SRO  missions  and  provides  immediate  on-line 
retrieval  of  mission,  track,  and  message  data.  To  accomplish  this,  GRISWI  provides  automated 
real-time  capture  and  processing  of  Reconnaissance  Information  Processing  System  (RIPS) 
format  messages,  and  maintains  a  mission  and  track  database  containing  schedule  and  resultant 
information.  GRISWI  generates  and  releases  outgoing  SRO  messages  to  the  Automated  Digital 
Network  (AUTODIN)  and  provides  on-line  query  and  report  capabilities  detailing  message, 
mission  status,  and  scheduling  information.  It  is  used  to  maintain  current  Track  Dictionary  data 
and  to  generate  the  master  copy  of  each  new  dictionary  or  set  of  change  pages.  GRISWI  has 
external  interfaces  with  the  GCCS  Automated  Message  Handling  System  (AMHS),  and  the  Joint 
Mapping  Toolkit  (JMTK). 

2.  System  Requirements 

GRISWI  runs  on  the  Solaris  platform. 

3.  Users/Training 

GRISWI  is  used  primarily  by  the  Joint  Reconnaissance  Centers  at  designated  Unified  Command 
sites. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Beverly  Walker,  (703)  735-8666. 

The  GCCS  Engineering  POC  is  Bob  Marion,  (703)  735-8578. 
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GSORTS  Input 

Readiness  Assessment  System  (RAS)  Input  Tool 

1.  System  Description 

The  GSORTS  RAS  Input  Tool  provides  an  icon  that  allows  GCCS  users  to  launch  a  web  browser 
session  and  connect  to  an  NT  server  located  at  the  NMCC.  This  enables  users  to  create,  add, 
modify,  delete,  and  generate  unit  status  reports  as  well  as  create  and  delete  unit  registrations. 
These  requirements  are  specified  in  Joint  Publication  1-03.3.  The  Input  Tool  uses  web-based 
technology  with  near  real  time  processing  to  replace  the  batch-processing  environment  currently 
used  for  input  transactions.  Thus  the  edits  will  be  applied  to  a  unit’s  status  report  immediately. 
This  ensures  that  a  unit  will  receive  immediate  feedback  on  inaccuracies  and  incorrectly 
formatted  submissions  will  not  be  accepted. 

2.  System  Requirements 

GSORTS  RAS  Input  Tool  runs  on  platforms  using  Microsoft  Windows  NT  version  4.0/Service 
Pack  4  operating  systems  and  has  dependencies  with  other  GCCS  software  segments.  The  Input 
Tool  requires  the  Netscape  Web  Browser  (WEBBr  4.0.3. 1)  and  CompT. 

3.  Users/Training 

The  Joint  Staff,  J3  Readiness  Division,  is  currently  coordinating  training  for  GSORTS  RAS 
Input  Tool  users  with  the  Services.  Training  is  presently  incorporated  into  the  Users  Manual. 
Embedded  training  is  the  eventual  goal  and  will  be  developed. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Craig  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Bob  Bovee,  (703)  681-2566. 
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GSORTS  Output 

Readiness  Assessment  System  (RAS)  Output  Tool 

1.  System  Description 

GSORTS  RAS  Output  Tool  is  a  user  friendly,  comprehensive  query  and  reporting  tool  used  to 
retrieve  and  analyze  data  from  SORTS  and  JOPES  databases.  The  system  uses  “point  and  click” 
technology  and  intuitive  interfaces  to  help  users  arrange  and  filter  data,  accessing  unit  resource, 
training,  organizational  hierarchy,  and  commitment  data.  The  system  also  has  an  advanced 
export  capability  to  allow  the  use  of  a  broad  range  of  commercial  off-the-shelf  software  for 
reporting  and  publishing,  such  as  Web  browsers,  word  processors,  spreadsheets,  and  presentation 
software.  Data  received  in  the  GSORTS  RAS  Output  Tool  is  displayed  in  the  GCCS-approved 
Web  browser  through  a  series  of  query  screens.  Users  can  navigate  screens  through  a  “point  and 
click”  procedure.  The  system  also  enhances  the  clarity  of  presenting  unit  readiness  status 
information  by  color  coding  the  displays.  CINC,  Service,  CSA,  and  Joint  Staff  requirements 
were  gathered  in  a  series  of  Joint  Application  Development  sessions. 

2.  System  Requirements 

The  GSORTS  RAS  Output  Tool  client  (RASQRY)  runs  on  platforms  using  Microsoft  Windows 
NT  version  4.0/Service  Pack  4  operating  systems  and  has  a  dependency  on  Netscape  Web 
Browser  (WEBBr  4.0.3. 1). 

The  GSORTS  RAS  Output  Tool  server  (RASSVR)  runs  on  platforms  using  Solaris  2.5.1 
operating  systems  and  has  a  dependency  on  the  GSORTS  client  database  segment  GORA 
5.0.0. 1,  Netsite  Web  Server  (WEBSv  1.0. 0.2),  and  Netscape  Web  Browser  (WEBBr  4.0.3. 1). 

3.  Users/Training 

The  Joint  Staff,  J3  Readiness  Division,  is  currently  coordinating  training  for  the  GSORTS  RAS 
Output  Tool  users  with  the  Services.  Training  is  presently  incorporated  into  the  Users  Manual. 
Embedded  training  is  the  eventual  goal  and  will  be  developed. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Craig  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Bob  Bovee,  (703)  681-2566. 
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JOPES  Editing  Tool  (JET) 


1.  System  Description 

The  JOPES  Editing  Tool  (JET)  provides  a  capability  to  create,  add,  modify,  delete  and  generate 
output  on  deployment-related  information  contained  in  an  Operation  Plan  (OPLANB)  tie  Phased 
Force  Deployment  Data  (TPFDD).  This  TPFDD  edit  capability  is  a  critical  tool  for  deliberate  or 
peacetime  planning  and  time-sensitive  or  Crisis  Action  Planning  (CAP). 

2.  System  Requirements 

JET  runs  on  the  Sun/Solaris  2.5.1  platform. 

3.  Users/Training 

JET  is  used  by  the  JOPES  community  in  the  Joint  Staff  and  Unified  Command  staffs. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  POC  is  Jane  Davis,  (703)  681-2582. 
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MAT 


1.  System  Description 

MAT  is  a  medical  planner’s  tool  that  provides  a  requirements  generator  (MAT-RG)  and  a  course 
of  action  analysis  (MAT-COAA)  module.  Previously,  two  separate  models  performed  these 
functions.  MAT  combines  these  two  functions  into  a  single  environment  and  provides  interfaces 
between  them  and  to  other  data  sources  and  automated  tools. 

2.  System  Requirements 

MAT  runs  on  the  Windows  NT  operating  system. 

3.  Users/Training 

MAT  will  be  provided  to  medical  planners  at  the  CINC,  Service,  and  CINC  component  level. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-  8611. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis  (703)  735-8764. 
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METOC  JMS/MIS 


1.  System  Description 

METOC  imports,  processes,  displays  and  disseminates  Meteorological  and  Oceanographic 
products  for  layered  overlay  on  the  COP.  It  is  a  high-level  decision  aid/briefing  tool  as  opposed 
to  a  forecasting  tool.  It  provides  the  use  of  “CNN”  type  symbology  to  present  environmental 
data  to  decision  makers.  Products  include  forecasts,  warnings,  gridded  field  data,  satellite 
imagery,  briefing  symbology,  and  observations.  Information  is  supplied  on  a  “push/pull”  basis. 
Operators  can  pull  JMV  bundles  containing  gridded  field  information,  satellite  (gif)  information 
and  observation  data  over  the  SIPRNET.  Various  Production,  Regional  and  AFLOAT  centers 
push  to  METOC.  Users  can  also  download  data  from  various  centers’  Web  pages.  METOC 
contains  six  segments.  Combined,  they  deliver  the  following  functionality: 

•  METOC  Imagery  -  allows  viewing,  animating,  and  management  of  METOC  image  format 
(MIF)  files;  overlay  of  static  and  animated  imagery  on  the  COP  using  JMTK. 

•  METCOM  Communications  -  allows  download  of  OTH-T  Gold  format  weather  data  from 
Fleet  numerical  SIPRNET  website.  Downloaded  data  can  be  viewed  as  raw  grid  data  and 
displayed  on  the  COP. 

•  GRID  Draw  -  allows  retrieval  of  gridded  data  which  can  be  drawn  on  the  COP. 

•  Object  Plot  -  allows  retrieval  and  display  of  environmental  data,  such  as  wind  barbs,  on  the 
COP. 

•  METOC  Overlays  -  a  draw  utility  which  allows  placing  METOC  symbology,  text,  etc.,  on  the 
COP.  These  overlays  can  be  transmitted  to  other  GCCS  sites. 

•  Editors  -  allows  creating,  storing,  and  displaying  surface  and  air  observation  data  on  the  COP. 
Environmental  Editor  allows  creation,  viewing,  editing  of  Bathy thermographic  and  Ocean  profile 
data  and  placing  it  on  the  COP. 

•  Brief  Utility  -  a  PowerPoint  like  presentation  builder  which  allows  use  of  lines,  text,  polygons, 
pixmap  and  METOC  symbols.  It  provides  capability  to  create  and  annotate  images,  or  pictures, 
and  assemble  them  into  products  for  electronic  briefings.  Graphics  created  can  also  be 
transmitted  to  other  users. 

•  METOC  Status  Board  -  a  presentation  tool  that  can  be  displayed  on  the  COP.  It  creates 
mission  scenarios  with  “RED/YELLOW/GREEN”  assessment  of  the  mission  based  on 
environmental  factors. 

•  METOC  Data  Server  -  Ingests  and  manages  meteorological  and  oceanographic  data  provided 
from  external  sources.  Provides  services  to  METOC  client  applications  desiring  environmental 
data. 

•  PARSER  -  Provides  message  parsers,  or  decoders,  for  OTH-T  Gold  messages.  Decodes  OTH-T 
Gold,  GRIDFLD,  RDSND,  BATHY,  MUNIT  and  NUNIT  messages. 

2.  System  Requirements 

METOC  JMS/IMS  runs  on  the  Solaris  Platfonn. 

3.  Users/Training 

METOC  is  used  by  meteorological  personnel  who  need  briefing  and  decision  aid  tools. 
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4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Jerry  Bennett  (7030  735-8282. 
The  GCCS  Engineer  POC  is  Cindy  Hopkins  (703)  735-8754. 
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METOC  Tactical  Forecast  System  (TFS) 

1.  System  Description 

The  METOC  Tactical  Forecast  System  (TFS)  segment  is  a  weather  forecast  system  that  provides 
communications,  data  management,  and  base  weather  station  capabilities  on  a  single  hardware 
platform.  Various  newly  developed  weather  capabilities  are  also  incorporated  in  TFS,  including 
communication  and  product  distribution  functionality  via  the  World  Wide  Web  and  graphical 
red-yellow-green  (go-no  go)  theater  weather  charts.  Web  capabilities  include  download  of 
Appendix  30  products  from  remote  sits  for  loading  into  the  local  TFS  database.  In  addition,  this 
capability  allows  the  local  user  to  place  documents  from  MS  Word,  Excel  and  MS  PowerPoint 
onto  the  local  web  pages  as  well  as  image  files  than  can  be  downloaded  from  other  sites  or 
created  locally.  TFS  can  receive  weather  products  from  the  Air  Force  Weather  Agency  and  other 
remote  locations  using  TCP/IP  and  HTTP.  From  these  input  data  sources,  the  TFS  develops  and 
maintains,  in  near  real-time,  an  in-theater  weather  composite  data  set.  The  TFS  receives, 
displays,  creates,  quality  controls,  and  transmits  weather  data  and  other  related  data,  in  deployed 
areas  to  C4I  customers.  The  TFS  mission  application  is  composed  of  two  software  segments:  (1) 
Tactical  Forecast  System  (TFS)  segment  and  the  (2)  TFS  Web  Application  segment. 

2.  System  Requirements 

METOC  TFS  runs  on  the  following  Solaris  platforms: 

•  Sun  SPARCstation  20  with  the  Turbo  GX  Plus  graphics  card  running  Solaris  2.5.1. 

•  Sun  Ultra  2  with  the  Creator3D  graphics  card  running  Solaris  2.5.1 . 

Additionally,  the  TFS  segment  must  reside  on  a  client  system  (i.e.,  must  reside  on  the 
workstation  that  the  forecaster  will  be  physically  using).  Each  client  workstation  that  will  be 
used  to  run  TFS  must  have  the  TFS  segment  physically  loaded. 

3.  Users/Training 

Due  to  the  depth  of  expertise  required  to  use  this  application,  only  a  trained  professional 
forecaster  who  has  completed  the  Weather  System  Support  Cadre  (WSSC)  tactical  weather 
systems  training  course  will  find  this  application  useful. 

Training  for  TFS  applications  will  be  made  available  through  the  Air  Force  Weather  Agency. 

The  depth  of  training  will  vary,  based  on  individual  experiences  with  forecasting  tools. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Jerry  Bennett,  (703)  735-8282. 

The  GCCS  Engineering  Office  POC  is  Cindy  Hopkins,  (703)  735-8754. 
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Microsoft  NetMeeting 


1.  System  Description 

The  Microsoft  NetMeeting  segment  provides  real-time  conferencing  along  with  several 
additional  features  such  as  communication  with  both  audio  and  video,  collaboration  on 
Windows-based  applications,  exchange  of  graphics  using  an  electronic  whiteboard,  file  transfers 
and  a  text-based  chart  program.  This  segment  is  a  partial  segment  that  verifies  that  the  Microsoft 
NetMeeting  software  has  been  installed  on  the  PC. 

2.  System  Requirements 

NetMeeting  runs  on  the  Windows  NT  4.0  operating  system  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  Microsoft  NetMeeting,  be  installed  on  the  target 
computer  before  the  segment  is  installed.  If  the  COTS  software  is  not  installed,  the  installation 
will  be  terminated.  Individual  services  or  GCCS  sites  are  required  to  procure  licensed  copies  of 
the  Microsoft  NetMeeting  software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764. 
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Microsoft  Office  97 


1.  System  Description 

Microsoft  Office  97  provides  a  complete  set  of  fully  integrated  office  automation  applications. 
This  segment  is  a  partial  segment  that  verifies  that  the  Microsoft  Office  97  application  has  been 
installed  on  the  PC. 

2.  System  Requirements 

Office  97  runs  on  the  Windows  NT  4.0  operating  system  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  Microsoft  Office  97,  be  installed  on  the  target 
computer  before  the  segment  is  installed.  In  addition,  the  Software  Release  Packs  one  and  two 
for  Microsoft  Office  97  must  be  installed  to  make  Microsoft  Office  97  Y2K  compliant.  If  the 
COTS  software  is  not  installed,  the  installation  will  be  terminated.  Individual  services  or  GCCS 
sites  are  required  to  procure  licensed  copies  of  the  Microsoft  Office  97  software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Jeff  Bognar,  (703)  735-8528. 
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PC-Xware 


1.  System  Description 

The  PC-Xware  segment  is  an  X-Windows  server  that  enables  a  user  to  display  and  use  X 
Window  based  applications  on  a  PC  running  Windows  NT.  PC-Xware  is  a  partial  segment 
whose  purpose  is  to  validate  that  the  commercial-off-the-shelf  (COTS)  application,  PC-Xware, 
has  been  installed  on  the  PC.  This  version  adds  the  Integ  directory  (containing  the  IntegNotes 
and  VSOutput  files)  and  changes  the  $MEMORY  value  to  18  to  reflect  the  value  stated  in  the 
SVD. 

2.  System  Requirements 

PC-Xware  runs  on  the  Windows  NT  4.0  operating  system  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  PC-Xware,  be  installed  on  the  target  computer  before 
the  segment  is  installed.  It  the  COTS  software  is  not  installed,  the  installation  will  be  terminated. 
Individual  services  or  GCCS  sites  are  required  to  procure  licensed  copies  of  the  PC-Xware 
software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  Office  POC  is  Jaime  Medero,  (703)  681-2590. 
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Remote  Dial-In 


1.  System  Description 

The  AT&T  STU  III  1910  Driver  (ATTSTU)  software  supports  MS  Windows  NT  remote  access 
to  the  1910  modem  and  allows  for  dial-up  server  connections  from  remote  users.  The  ATTSTU 
software  segment  hosts  the  SDD1910  (aka  AT&T  Secure  Data  1910  External  Modem)  driver 
software  that  configures  the  remote  access  dialing  for  modem  Model(s)  1 100,  2100,  4100, 
SDD1900,  and  SDD1910  hardware.  This  version  of  ATTSTU  contains  driver  software  that 
configures  and  handles  Model  response  delays,  including  carrier,  secure  call,  “failed  at  14400 
retrying”,  “failed  at  9600  retrying”,  and  General  Dynamics  Secure  Communications  Systems’ 
STUN  10  Model  400/500  responses. 

2.  System  Requirements 

The  Remote  Dial  AT&T  STU  III  1910  Driver  (ATTSTU)  runs  on  the  Windows  NT  4.0  operating 
system.  The  segment  requires  that  the  commercial  off-the-shell  (COTS)  product,  AT&T  STU  III 
1910  Driver  (ATTSTU),  be  installed  on  a  Pentium  Personal  Computer  or  higher  processor. 
ATTSTU  requires  an  AT&T  STU  III  modem. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764. 
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Rapid  Query  Tool  (RQT) 


1.  System  Description 

The  Rapid  Query  Tool  (RQT)  is  a  prototype.  It  consists  of  one  segment,  the  RQT  Client.  No 
RQT  specific  database  segment  is  required.  It  is  intended  to  perform  all  the  critical  functions  of 
legacy  JOPES  Ad  Hoc  Query  (AHQ),  but  at  a  much  higher  speed.  It  is  a  rapid  Operation  Plan 
(OPLAN)  query  tool.  It  uses  a  new  approach  that  provides  a  fast,  flexible,  and  complete  solution 
to  a  user’s  OPLAN  query  needs.  RQT  provides  a  wide  range  of  user-defined  data  representation 
and  format  options  for  viewing  and  printing  OPLAN  data.  RQT  creates  a  “snapshot”  of  OPLAN 
data  through  rapid  retrieval  using  parallel  processing.  This  snapshot  is  saved  on  the  Client 
workstation  and  is  used  when  generating  reports.  This  approach  allows  report  tailoring  “on  the 
fly”  and  greatly  reduces  the  number  of  times  the  GCCS  Oracle  database  is  accessed.  RQT 
provides  the  user  with  a  comprehensive  JOPES  data  retrieval,  analysis,  and  output  tool.  The 
primary  goal  in  the  development  of  RQT  is  providing  the  JOPES  user  community  with  a  total 
OPLAN  data  analysis  tool  with  the  absolute  maximum  performance.  Speed  does  not  come 
without  the  application  of  processing  power.  RQT  does  this  by  taking  advantage  of  the  database 
server’s  capability  to  manage  multiple  processors  and  processes.  RQT  creates  multiple 
processes  to  extract  data,  thus  eliminating  the  time-consuming  bottleneck  of  multiple  ORACLE 
table  joins.  After  the  data  is  retrieved,  it  is  then  merged  into  a  single  “snapshot”  for  analysis. 

The  multiple  processes  are  prioritized  and  managed  by  the  database  server  operating  system  in 
consideration  of  server  demands  to  perfonn  other  tasks.  It  is  to  the  user’s  advantage  that  the 
operating  system  puts  as  much  computing  power  as  available  to  accomplish  the  retrievals  and 
merge  the  data.  This  is  done  quickly  and  efficiently  as  opposed  to  long  tenn,  slow  processes  that 
tend  to  bog  the  system  down. 

2.  System  Requirements 

RQT  resides  on  the  Solaris  Platform.  The  installation  and  runtime  requirements  are  as  follows: 
GCCS  Account  Group  (GCCS),  ORACLE  Client  Applications  (ORAC),  ORACLE  Client  Tools 
2  (ORAT2)  and  TCL  (TCL). 

3.  Users/Training 

RQT  was  developed  for  the  JOPES  user  community.  Training  will  be  included  in  the  JOPES 
course  by  the  JOPES  Training  Organization  at  Scott  Air  Force  Base.  In  addition,  there  is 
excellent  training  information/examples  contained  in  the  Users  Guide,  CM  500-373-15,  which 
can  be  downloaded  from  the  DISA  Homepage. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj  Cooper  (703)  735-8611. 

The  GCCS  Engineer  POC  is  Jane  Davis  (703)  681-2582. 
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Seagate  Backup 


1.  System  Description 

The  Seagate  Backup  provides  the  tools  to  perform  automated  backups  of  critical  data  on 
Windows  NT  servers.  This  segment  is  a  partial  COTS  segment  that  verifies  that  the  Seagate 
Backup  application  has  been  installed  on  the  PC.  This  version  adds  the  Integ  directory 
(containing  the  IntegNotes  and  VSOutput  files)  and  changes  the  $MEMORY  value  to  18  to 
reflect  the  value  stated  in  the  SVD. 

2.  System  Requirements 

Seagate  Backup  runs  on  the  Windows  NT  4.0  platform. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764 
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Secret  Agent 


1.  System  Description 

Secret  Agent  3.1  is  a  file  encryption  utility  containing  implementations  of  the  most  secure  and 
popular  encryption  and  authentication  algorithms  available  today.  This  segment  is  a  partial 
segment  that  verifies  that  the  AT&T  Secret  Agent  application  has  been  installed  on  the  PC.  This 
version  adds  the  Integ  directory  (containing  the  IntegNotes  and  VSOutput  files)  and  changes  the 
$MEMORY  value  to  18  to  reflect  the  value  stated  in  the  SVD. 

2.  System  Requirements 

Secret  Agent  runs  on  the  Windows  NT  4.0  operating  system  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  AT&T  Secret  Agent,  be  installed  on  the  target 
computer  before  the  segment  is  installed.  If  the  COTS  software  is  not  installed,  the  installation 
will  be  terminated.  Individual  services  or  GCCS  sites  are  required  to  procure  licensed  copies  of 
the  AT&T  Secret  Agent  software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764. 
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Adaptive  Course  of  Action  (ACOA) 


1.  System  Description 

The  Adaptive  Course  of  Action  (ACOA)  system  stores  plans  in  a  Campaign  Object  server  so  that 
plans  are  available  at  all  times  to  operational  planners  at  all  levels  of  planning  and  at  different 
geographical  sites.  ACOA  provides  a  distributed  collaborative  environment  through  the 
following  segments: 

Web  Planner:  The  Web  Planner  consists  of  an  integrated  set  of  planning  tools  served  unifonnly 
from  a  web  site  that  is  accessible  by  a  standard  web  browser.  Web  Planner  planning  tools  are 
integrated  at  three  levels,  the  graphical  user  interface  level,  the  data  representation  level  and  the 
data  service  level. 

All  tools  in  the  Web  Planner  toolset  share  a  common  look  and  feel.  All  tools  access  and 
manipulate  the  same  underlying  plan  data,  which  is  stored  in  a  common  object-oriented 
architecture  and  served  through  a  CORBA-based  server.  Plan  data  used  by  Web  Planner  tools  is 
accessible  by  other  applets  and  applications  through  the  same  distributed  plan  service 
architecture. 

The  Dynamic  Operations  Planning  Tool  (DOPT)  is  a  sequenced  guidance  tool,  which  takes  a 
planner  through  the  necessary  steps  of  operational  planning  in  an  ordered  manner.  Through  the 
DOPT,  the  planner  inputs  infonnation,  which  results  in  the  generation  of  standard  documents 
and  orders,  selection  of  a  CJTF,  the  selection  of  a  course  of  action  (COA),  and  the  association  of 
forces  with  a  COA. 

The  Course  of  Action  Selection  Tool  (COAST)  helps  the  planner  to  specify  alternative  COAs  for 
a  campaign,  establish  criteria  by  which  to  evaluate  the  effectiveness  of  the  various  COAs,  and 
perform  computations,  which  compare  and  rank  the  COAs  according  to  their  ability  to  meet  the 
selected  criteria.  COAST  screens  capture  the  analyses  performed  in  COA  evaluation  in  a  color 
display,  which  is  useful  for  inclusion  in  briefs  and  slides,  to  document  the  decision-making 
process. 

Microsoft  Office  tools  are  integrated  into  the  toolset  for  document  and  slide  generation. 

Multicast  collaboration  tools  provide  the  planner  with  VTC  and  whiteboard  collaboration 
capability.  Tools  for  force  selection,  TPFDD  generation  and  scheduling  are  currently  in 
development. 

LEIF:  The  Lightweight  Extensible  Information  Framework  (LEIF)  is  both  an  application  and  an 
open  software  development  framework.  As  a  Command  and  Control  (C2)  and  Information 
Technology  application,  LEIF  presents  a  client  interface  to  the  operator.  As  an  open  framework, 
LEIF  offers  lightweight,  client-oriented  core  architecture,  with  no  required  middle -tier  or  server 
capabilities.  LEIF  provides  the  means  to  collect  data  from  various  sources,  combine  the  data 
intelligently,  and  display  the  data  in  various  dimensions  and  configurations  (maps,  data  plots, 
time  plots,  tables,  spreadsheets,  etc.).  Data  sources,  data  views  and  other  data  processing  tools 
are  integrated  into  LEIF  as  independently  developed  LEIF  extensions  (i.e.,  plug-in  modules). 
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Odyssey:  Odyssey  is  a  standalone  Java  Application  that  runs  independently  of  a  browser. 
Odyssey  is  a  method  (a  way  of  doing)  and  a  framework  (a  way  of  thinking)  when  conducting 
distributed  collaborative  planning  activities.  It  provides  an  over-arching  graphical  interface  that 
requires  little  or  no  training  but  provides  a  powerful  context  in  which  to  do  strategic  level 
planning.  Odyssey  provides  general  collaboration  services  and  unlimited  access  to  other 
electronic  tools  that  a  planner  may  need  in  the  course  of  his/her  duties.  Operational  personnel 
can  quickly  find  and  use  disparate  tools  in  the  development  of  complex  plans,  requiring  input 
from  numerous  sources. 

Geospatial  Force  Planning  Tool  (GFPT):  GFPT  provides  a  visual,  time -phased,  map-based 
planning  environment  for  users  to  develop  their  operational  plan.  The  system  will  allow  the  user 
to  select  forces  and  assign  tasks  by  drawing  their  respective  symbols  on  top  of  a  digital  map.  The 
mapping  environment  is  provided  through  integration  of  the  LEIF  and  the  COP.  The  user  will 
also  have  the  ability  to  select  various  objects/tasks  and  view  property  windows  describing  the 
object’s  attributes.  If  desired,  further  drill-down  will  be  possible  to  follow  links  back  to  the 
object’s  data  source.  For  example,  if  the  user  has  selected  a  unit  (ship,  armored  division,  etc),  the 
drill-down  links  will  pull  the  unit’s  home  page.  This  will  display  the  units  GSORTS  data  such  as 
Readiness  levels. 

Virtual  Situation  Book  (VSB)/Virtual  Plan  Book  (VPB):  VSB/VPB  intelligently  organizes 
and  presents  a  condensed  overview  of  a  particular  topic.  The  VSB/VPB  makes  use  of  advanced 
visualization  formats  (dynamically  tailored  to  users)  with  drill-down  that  enable  quick 
understanding  of  the  important  elements  of  a  crisis  situation.  VSB/VPB  is  a  multimedia 
container  for  live  distributed  objects  (objects  are  connected  to  pertinent  data  sources).  VSB/VPB 
objects  are  represented  in  multi-dimensional,  hierarchical  and  multi-scale  forms.  Temporal 
analysis  is  supported.  To  support  drill-down,  VSB/VPB  makes  use  of  a  Knowledge  Broker 
Agent  to  intelligently  access  the  repositories  needed  to  elaborate  the  infonnation  shown  by  the 
live  objects. 

Intelligent  Process  Manager  (IPM):  IPM  is  a  foundation  technology  for  ACOA.  It  consists  of 
IPM/Process  Design  and  Reengineering  (IPM/PDR)  and  IPM/Process  Monitoring  and 
Visualization  (IPM/PMV).  IPM/PDR  is  a  process  design,  verification,  visualization,  and  analysis 
tool  with  multiple  means  for  entering  a  process  model  and  with  email-based  facilities  for 
importing  processes  specified  in  Excel  or  ProcessScript.  IPM/PMV  is  a  collaborative  process 
monitoring  and  visualization  tool  with  facilities  for  tracking  the  status  of  individual  activities  and 
rolling  up  the  individual  activity  status  to  determine  the  status  of  the  parent  processes. 

IPM/PDR  is  used  on  ACOA  to  define/capture,  verify,  and  catalog  component  CAPE  processes  at 
multiple  levels  of  abstraction.  These  component  processes  or  process  fragments  are  the  building 
blocks  for  constructing  process  models  for  CAPE  scenarios.  IPM/PDR  is  being  used  to  create  a 
library  of  reusable  ACOA  process  fragments  (assets).  This  library  will  support  the  composition 
of  a  CAPE  process  model  for  a  particular  mission.  The  resulting  model  will  be  used  by 
IPM/PMV  to  monitor  and  visualize  the  state  and  status  of  the  overall  process.  It  does  so  by 
rolling  up  the  status  of  the  individual  activities  (i.e.  leaf  nodes)  and  subprocesses  from  lower 
levels. 
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2.  System  Requirements 

ACOA  runs  on  the  Windows  NT  4.0  platfonn. 

3.  Users/Training 

ACOA  is  intended  for  use  by  all  GCCS  operational  planners.  Training  will  be  embedded  in  the 
ACOA  system. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Maj  Copper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Bob  Marion,  (703)  735-8578. 
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Automated  Joint  Monthly  Readiness  Review  (AJMRR) 


1.  System  Description 

The  Automated  Joint  Monthly  Readiness  Review  (AJMRR)  program  provides  an  automated 
capability  supporting  the  Joint  Staffs  Joint  Monthly  Readiness  Review  (JMRR)  analysis  and 
brief-building  process.  Its  objective  is  an  expedited  and  accurate  JMRR  product  to  support  Joint 
Staff  and  OSD  force  management  and  procurement  issue  resolution  and  decision  making. 
AJMRR  is  the  Joint  Readiness  Extension  of  the  Advanced  Joint  Planning  (AJP)  ACTD.  AJMRR 
provides  the  JMRR  reporting  community  with  standardized  input  screens,  web  publishing  tools 
and  the  connectivity  to  exchange  any  type  of  readiness  information.  The  system  will  also  keep  a 
database  of  all  readiness  information.  This  database  will  give  users  the  ability  to  look  at 
previous  slides  and  make  decisions  based  on  past  data.  It  will  also  assist  users  in  analyzing 
trends  in  readiness  infonnation. 

2.  System  Requirements 

AJMRR  runs  on  the  Solaris  platfonn. 

3.  Users/Training 

AJMRR  is  used  by  the  Joint  Staff  and  the  Joint  Monthly  Readiness  Review  reporting 
community. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Kerry  Weathington,  (703)  735-8662. 

The  GCCS  Engineering  Office  POC  is  Bob  Bovee,  (703)  681-2566. 
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AMHS  Message  Manager  (AMHSMM) 


1.  System  Description 

AMHSMM  is  a  specially  developed  application  that  provides  a  central  message  management  and 
tasking  system.  It  allows  the  user  to  access  AUTODIN  message  traffic  from  the  GCCS  NT 
platform.  It  is  the  part  of  AMHS  that  resides  on  GCCS. 

2.  System  Requirements 

AMHSMM  runs  on  the  NT  4.0  platform. 

3.  Users/Training 

AMHSMM  is  designed  to  aid  personnel  in  the  performance  of  Automated  Digital  Network 
(AUTODIN)  message  review,  generation,  coordination,  and  release  duties. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  POC  is  Ken  Fagan,  (703)  735-8643. 
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COMPASS 


1.  System  Description 

COMPASS  is  a  set  of  Government  Off-The-Shelf  (GOTS)  and  Commercial  Off-The-Shelf 
(COTS)  software  services.  COMPASS  provides  a  non-intrusive  middleware  approach  that 
facilitates  Collaborative  Planning,  Modeling  &  Simulation  (CPM&S)  access  as  well  as 
Distributed  Collaborative  Planning  (DCP)  to  the  Joint-Combined  Arms  environment. 

COMPASS  allows  planners  using  disparate  mission  planning  systems  to  move  between  local 
planning,  collaborative  planning,  analysis,  and  simulation-based  rehearsal  modes.  COMPASS 
capabilities  include  a  client-server  architecture  with  session  management  (SMGT)  tools,  a  shared 
overlay  manager  (SOM),  a  composite  route  preview  (CRP)  capability,  COTS  DCP  tools,  GOTS 
DCP  server  tools,  and  the  ability  to  observe  external  M&S  products  on  host  C4I  and  mission 
planning  systems. 


COMPS  (SOL,  NT) 

[GOTS] 

The  COMPASS  server  segment  is  a  set  of  four  tightly  integrated  servers:  Session 
Management  (SMGT),  Shared  Overlay  Management  (SOM),  Composite  Route  Preview 
(CRP),  and  Track/Simulation  Management  (TSM).  Each  of  the  COMPASS  servers  has  a 
companion  client  library  that  is  integrated  within  a  modeling,  planning,  or  simulation 
client  application  (e.g.,  GCCS,  CTAPS,  AFMSS,  and  ModSAF).  These  client  libraries 
process  remote  procedure  calls  from  the  client  application  to  their  companion  server  in 
order  to  exchange  modeling,  planning,  and  simulation  data  with  other  client  applications 
via  the  COMPASS  server.  COMPS  also  provide  two  applications:  Server  Control  (for 
starting  and  monitoring  COMPASS  sessions)  and  Test  Client  (for  developmental  testing 
or  COMPASS  session  monitoring). 

COMPC  (HP,  SOL,  NT) 

[GOTS] 

The  COMPASS  client  library  segment  is  a  set  of  four  statically  or  dynamically  linkable 
function  libraries  (SMGT,  SOM,  CRP,  and  TSM).  These  libraries  are  code-integrated 
within  a  COMPASS  client  application  and  process  remote  procedure  calls  from  the  client 
application  to  their  companion  COMPASS  server  in  order  to  exchange  modeling, 
planning,  and  simulation  data  with  other  COMPASS  client  applications. 

GCPA  (HP,  SOL) 

[GOTS] 

The  GCCS  Collaborative  Planning  Application  (GCPA)  is  a  DII  COE  compliant 
application  that  uses  the  COMPASS  Client  Libraries  (COMPC)  to  exchange  planning, 
modeling,  and  simulation  information  with  other  COMPASS-capable  systems  via  the 
COMPASS  servers  (COMPS).  GCPA  uses  the  DII  COE  Joint  Mapping  Tool  Kit 
(JMTK),  the  Track  DataBase  Manager  (TDBM),  and  the  UB  communications 
infrastructure  to  interface  with  the  underlying  GCCS  system.  Every  message  received 
from  the  COMPASS  servers  by  the  GCPA  is  processed  and  represented  in  some  way  to 
the  user  of  the  GCPA,  either  on  the  GCPA  GUI  or  the  GCCS  system  chart.  GCPA  also 
has  menu  options  to  launch  multimedia  applications  such  as  audio,  video,  chat,  and 
whiteboard. 

GCPA  Patch  1  (HP,  SOL) 

[GOTS] 

GCPA  Patch  1  modifies  the  GCCS  Account  Group  segment  (after  installation  of  the 
CVWC  segment)  to  enable  launch  of  the  CVWC  application  from  the  main  menu. 

CVWC  (HP,  SOL) 

[Public  Domain,  licensed  by 

Mitre] 

Version 

The  Collaborative  Virtual  Workspace  (CVW)  client  segment  provides  an  intuitive 
method  for  the  COMPASS  user  to  enter  and  leave  COMPASS  sessions.  CVWC 
automatically  launches  and  terminates  COMPASS  applications  to  reduce  workstation 
user  workload  in  a  distributed  collaborative  planning  environment.  See  also  SD,  an 
alternate  method  for  launching  VAT  and  VIC/NV. 
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CVWC  Patch  1  (HP, SOL) 

[Public  Domain,  licensed  by 

Mitre] 

CVWC  Patch  1  modifies  CVWC  to  enable  launch  and  termination  of  GCPA  and  RWC 
as  COMPASS  sessions  are  entered  or  left  by  the  workstation  user.  Unpatched  CVWC 
launches  and  tenninates  only  VAT  and  VIC. 

CVWS  (SOL) 

[Public  Domain,  licensed  by 
Mitre] 

Version 

The  Collaborative  Virtual  Workspace  (CVW)  server  segment  provides  a  central 
administrative  facility  for  setting  up  virtual  conference  centers  and  their  subordinate 
sessions.  Virtual  conference  centers  and  their  sessions  are  accessed  by  CVWC. 

RWS  (SOL,  NT) 

[COTS,  licensed  by  VisualTek 
Solutions,  Inc] 

The  Rendezvous  Whiteboard  server  segment  is  the  server  component  of  an 
Intemet/Intranet  Whiteboard.  RWS  allows  simultaneous  text  sessions,  drawing  on  a 
shared  canvas,  file  and  document  sharing,  and  screen  and  image  sharing  and  annotation. 
Rendezvous  provides  server  “channels,”  allowing  large  workgroups  to  share  information 
simultaneously.  Rendezvous  implements  GroupWare  technologies  such  as  shared 
whiteboards,  shared  documents,  text  communication  rooms,  collective  browsing  in  a 
consistent  work  environment.  Rendezvous  is  compatible  with  TCP/IP  based  networks. 

RWC  (HP,  SOL,  NT) 

[COTS,  licensed  by  VisualTek 
Solutions,  Inc] 

The  Rendezvous  Whiteboard  client  segment  is  the  client  component  of  an 
Internet/Intranet  Whiteboard.  See  RWS  for  additional  details. 

SD  (HP,  SOL,  NT) 

[Public  Domain,  no  licensing] 

Session  Directory  is  a  multicast  backbone  (MBONE)  application  that  provides  (1)  an 
easy  way  to  create  multicast  sessions,  (2)  a  facility  to  advertise  new  session(s)  and  (3)  a 
dynamically  updated  list  of  available  sessions  (e.g.,  VAT  audio  conferences,  and  NV  or 
VIC  videoconferences).  SD  is  used  in  COMPASS  98  as  an  alternate  method  for  setting 
up  and  launching  audio  (VAT)  and  videoconferences  (VIC/NV). 

VAT  (HP,  SOL,  NT) 

[Public  Dornain.no  licensing] 

Visual  Audio  Tool  allows  users  to  conduct  host-to-host  or  multihost  audio 
teleconferences  over  an  Internet  (multihost  conferences  require  that  the  kernel  support  IP 
multicast).  On  most  architectures,  no  hardware  other  than  a  microphone  is  required  - 
sound  I/O  is  via  the  built-in  audio  hardware. 

VIC  (HP,  SOL,  NT) 

[Public  Domain,  no  licensing] 

Primary  video  conferencing  application  for  COMPASS  98.  Video  Conferencing  (VIC) 
was  designed  with  a  flexible  and  extensible  architecture  to  support  heterogeneous 
environments  and  configurations.  For  example,  in  high  bandwidth  settings,  multi¬ 
megabit  full-motion  JPEG  streams  can  be  sourced  using  hardware  assisted  compression, 
while  over  lower  bandwidth  enviromnents  like  the  Internet,  aggressive  low  bit-rate 
coding  can  be  carried  out  in  software.  VIC  is  based  on  version  2  of  the  Real-time 
Transport  Protocol  (RTP),  which  provides  basic  real-time  media  communication  support. 
RTP  is  an  application-level  protocol  and  is  implemented  entirely  within  VIC  —  no 
special  system  enhancements  needed  to  run  RTP.  Although  VIC  can  be  run  point-to- 
point  using  standard  unicast  IP  addresses,  it  is  primarily  intended  as  a  multiparty 
conferencing  application. 

NV  (Sun) 

[Public  Domain,  no  licensing] 

Alternate  video  conferencing  application  for  COMPASS  98.  Network  Video  allows 
users  to  transmit  and  receive  slow  frame  rate  video  via  UDP/IP  across  an  Internet.  Video 
streams  can  be  either  sent  point  to  point,  or  sent  to  several  destinations  simultaneously 
using  IP  multicast.  Receivers  need  no  special  hardware  -  just  an  X  display.  Transmitters 
need  some  sort  of  frame  capture  hardware  (e.g.,  Sun  Video  Card  part  number  X1085A) 

NVAT  (NT) 

[Public  Domain,  no  licensing] 

Alternate  video  conferencing  application  for  COMPASS  98.  Network  Video  Audio  Tool 
(NVAT)  is  an  audio/video  application  for  Windows  95  and  Windows  NT,  compatible 
with  NV  and  VAT.  Uses  RTPvl . 

2.  System  Requirements 

COMPASS  has  Solaris,  HP  and  NT  segments.  Its  additional  hardware  requirements  are  as 
follows: 

Video  Card  (e.g.,  Sun  Part  #  X1085A)  for  video  transmission  using  Video  Conferencing  (VIC) 
[not  required  for  video  reception] 
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NTSC  Video  Camera  for  video  transmission  using  Video  Conferencing  (VIC)  [not  required  for 
video  reception] 

Microphone  for  audio  transmission  using  Visual  Audio  Tool  (VAT) 

3.  Users/Training 

Collaborative  planners  use  the  COMPASS  application. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj.  Cooper  (703)  735-8611. 

The  GCCS  Engineer  POC  is  LCDR  Otis,  (703)  735-8764. 
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Defense  Message  System  (DMS)  Microsoft  Outlook  98 


1.  System  Description 

The  Defense  Message  System  (DMS)  Microsoft  Outlook  98  User  Agent  (UA)  adds  specific 
features  to  the  commercial  Outlook  technology  to  comply  with  the  specifications  set  by  the 
United  States  Department  of  Defense  (DoD).  It  offers  messaging  and  groupware  capabilities, 
and  supports  universal  connectivity.  DMS  Microsoft  Outlook  98  User  Agent  will  be  used  for 
DII  COE-based  application  segments  on  the  Global  Command  and  Control  System  (GCCS). 
This  segment  is  an  abbreviated  segment  for  the  NT-platform. 

2.  System  Requirements 

DMS-T  Outlook  98  runs  on  the  NT  4.0  platform. 

3.  Users/Training 

For  sending  and  receiving  messages  over  networks.  This  user  agent  resides  on  the  client,  and 
offers  FORTEZZA  security  capabilities  (a  security  measure  endorsed  by  the  Department  of 
Defense  (DoD). 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  POC  is  Ken  Fagan,  (703)  7351-8643. 
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Force  Module  Editor  (FMEDIT) 


1.  System  Description 

Force  Module  Editor  (FMEDIT)  is  an  application  which  can  create  multiple  levels  of 
hierarchically  arranged  force  modules  (FM)  to  complement  the  single  level  of  FMs  in  TPEDIT. 
FMEDIT  has  the  capability  to  expand  dramatically  in  terms  of  constructing  FMs  based  on 
attributes  such  as  mission,  capabilities,  etc,  which  allows  much  improved  flexibility  in 
deployment  planning  and  a  tighter  coupling  of  the  employment  plan  and  the  deployment  plan. 
FMEDIT  is  a  part  of  the  Joint  Planning  and  Execution  Toolkit  (JPET)  that  also  includes  the  JTF 
Map  System  (MATT),  TPFDD  Editor  (TPEDIT),  and  Theater-level  Analysis,  Replanning,  and 
Graphical  Execution  Toolkit  (TARGET)  software. 

2.  System  Requirements 

FMEDIT  requires  Oracle  Client  Applications  (ORAC),  FMEDIT  Database  (FMDATA),  and 
TPEDIT  Data  (TPDATA)  segments  to  be  installed  on  the  Oracle  Database  Server  before 
installation. 

3.  Users/Training 

JPET  users  will  use  FMEDIT  for  collaborative  planning  and  crisis  action  planning. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  point  of  contact  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  point  of  contact  is  Bob  Marion,  (703)  735-8578. 
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Integrated  Imagery  and  Intelligence  (13) 


1.  System  Description 

The  GCCS  Integrated  Intelligence  and  Imagery  (13)  is  a  tool  that  overlays  Defense  Intelligence 
Agency  data,  Order  of  Battle  and  targets  on  imagery  using  Joint  Mapping  Tool  Kit  (JMTK).  13 
enhances  GCCS  with  the  ability  to  access  military  intelligence  imagery  assets.  It  provides 
necessary  intelligence  features  to  the  warfighter  and  consists  of  44  segments  which  comprise 
several  key  databases  and  activities.  Major  segments  and  some  of  the  key  functions  are  as 
follows: 

•  Imagery  Management  Database  segment  -  provides  for  intelligence  imagery  by  storing  data  on 
location  and  type  of  imagery 

•  Navy  Intelligence  Database-  stores  characteristics  and  performance  data  for  aircraft,  helicopters, 
ships,  submarines  and  missiles 

•  Intelligence  Database  Applications  -  includes  SQL  stored  procedures  that  enhances  data  retrieval 
supporting  JMHS  and  Intelligence  Mission  applications 

•  General  Military  Intelligence  Database  -  stores  order  of  battle,  facilities  and  unit  data 

•  ICS  Server  -  provides  ability  to  send  and  receive  digital  imagery  files  over  full-duplex,  half¬ 
duplex  and  simplex  communications  channels 

•  Intelligence  Database  Global  Data  -  global  configuration  data  for  DIA’s  MIDB  applications 

•  Message  Handling  Services  Sybase  Data  Interface  -  provides  capability  to  receive  messages  and 
store  message  text  for  later  use 

•  TC4IDB  Aggregate  -  parent  aggregate  for  a  number  of  Intelligence  Shared  Data  Servers 
segments.  Facilitates  installation  of  those  segments 

2.  System  Requirements 

Integrated  Imagery  and  Intelligence  (13)  is  hosted  on  the  Solaris  and  HP  platforms. 

3.  Users/Training 

Initial  training  will  be  conducted  through  the  use  of  Mobile  Training  Teams,  tailored  for  13 
functionality.  Lessons  learned  from  the  early  CENTCOM  assessment  will  be  incorporated  into 
future  training. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Bob  Garland  (703)  735-8936.. 

The  GCCS  Engineer  POC  is  Mike  Greifner  (703)  681-2479. 
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Information  Dissemination  Management  (IDM) 


1.  System  Description 

IDM  tools  and  services  assist  in  the  identification  and  characterization  of  appropriate  information 
and  in  its  retrieval  and  delivery  to  appropriate  users  while  accommodating  heterogeneous 
communications  networks  with  intermittent  availability.  IDM  is  that  set  of  policies,  procedures, 
tactics  and  techniques  which  has  for  its  goal  the  provision  of  the  “right  information  at  the  right 
place  at  the  right  time.”  IDM  accomplishes  this  by  providing  profiling,  cataloging  and  search 
capabilities  for  network  based  information  repositories,  i.e.  “smart  pull.” 

2.  System  Requirements 

IDM  runs  on  the  Sun/Solaris  2.5.1  platform. 

3.  Users/Training 

IDM  users  are  comprised  of  the  CINC  and  his  Staff  down  to  the  Joint  Task  Force  (JTF) 
components.  IDM  provides  the  capability  for  the  warfighter  and  commander  to  determine  which 
information  is  to  be  “dynamically  forward  deployed”  (i.e.,  infonnation  moved  into  the  theater 
from  remote  source  repositories  periodically  and  automatically  based  on  the  warfighter’s 
profile.)  The  warfighter  profile  states  the  infonnation  needs  of  the  warfighter,  nominally  using 
metadata  to  describe  the  type  of  information  desired  (e.g.,  weather  in  Germany).  The  profile  also 
specifies  where  that  information  should  be  sent  and  at  what  frequency  (i.e.,  every  10  days,  every 
8  hours).  A  warfighter  profile  may  apply  to  an  individual  or  group  of  users.  Infonnation 
searched  and  retrieved  by  IDM  services  can  be  generated  in  theater,  at  a  CONUS  garrison 
location,  or  at  a  national  source,  and  can  originate  directly  from  the  source  generator  or  from  a 
temporary  storage  or  archive  function.  IDM  allows  information  flow  to  be  controlled  according 
to  preset  priorities.  This  ensures  that  mission-critical  infonnation  is  provided  to  the  warfighters 
in  a  timely  and  efficient  manner.  IDM  users  are  Commanders  who  set  information  priorities  and 
profiles  for  their  AOR  users  and  infonnation  consumers  thus  providing  effective  infonnation 
awareness,  access,  and  delivery  to  the  warfighter. 

IDM  training  is  comprised  of  users  manuals  and  associated  documentation  as  well  as  planned 
embedded  application  training  methods  and  techniques. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Craig  Cooper,  (703)  735-8611. 

The  GCCS  Engineering  Office  POC  is  Russell  Smith,  (703)  681-2482. 
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Joint  Defensive  Planner  (JDP) 


1.  System  Description 

JDP  is  a  mission  application  for  preparing  and  evaluating  Air  Defense  Plans.  The  JDP 
application  allows  the  user  to  evaluate  candidate  defense  strategies  against  theater  ballistic 
missile,  cruise  missile,  and  aircraft  attacks.  Planners  interact  with  a  Graphical  User  Interface 
(GUI)  to  set  up  different  air  defense  courses  of  action  (CoAs),  including  alternative  force 
deployments  and  defense  priorities.  Planners  can  evaluate  air  defense  CoAs  using  analytic 
weapon-  and  sensor-coverage  utilities,  and  force-on-force  simulations.  Optimization 
functionality  may  be  used  to  produce  alternative  radar  deployments  that  may  subsequently  be 
analyzed  using  the  JDP  analysis  tools.  JDP  has  the  capability  to  produce  and  import  a 
TACOPDAT  message  to  disseminate  defensive  plans. 

2.  System  Requirements 

Sun  SPARCstation  20  or  better  running  Solaris  2.5.1  with  at  least  8  GB  HD  and  300  MB  RAM. 

3.  Users/Training 

The  JDP  application  is  designed  to  assist  Theater  Air  and  Missile  Defense  (TAMD)  planning 
staffs  of  the  commanders  in  chiefs  (CINCs),  Joint  Force  Commander  (JFC),  Area  Air  Defense 
Commander  (AADC),  Regional  Air  Defense  Commander(s)  (RADC),  and  Component 
Commanders  in  the  development  of  operational  level  joint  TAMD  plans  to  counter  air  and 
missile  threats. 

9 

Training  for  the  JDP  application  is  available  through  the  Air  Force  C  Warrior  School,  Hurlburt 
Air  Force  Base,  Florida. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Bob  Garland,  (703)  735-8936. 

The  GCCS  Engineering  Office  POC  is  Lt  Col  Merrick,  (703)  735-8683. 
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Joint  Forces  Requirements  Generator  (JFRG)  II 


1.  System  Description 

Joint  Forces  Requirements  Generator  (JFRG)  II  is  a  PC  application  to  support  remote  and 
forward  deployed  users  in  generating  Time  Phased  Force  Deployment  Data  (TPFDD).  JFRG 
provides  a  unit-level  deployable,  microcomputer-based  deployment  planning  tool  for  the  Joint 
community.  JFRG  accelerates  the  development,  sourcing,  analysis,  and  refinement  of  plans  and 
deployment  databases  resulting  in  executable  JOPES  TPFDD.  It  will  provide  a  bridge  between 
JOPES  and  the  TCAIMS  II  system,  and  reduce  response  time  by  more  efficiently  creating  and 
refining  plans  that  can  be  accomplished  directly  in  JOPES.  JFRG  prepares  timely  initial 
estimates  through  the  use  of  standard  reference  data  and  analysis  tools.  It  facilitates 
identification  of  accurate  unit  data  down  to  the  unit  personnel  and  Level  4  cargo  detail.  It 
consolidates  joint  and  service-specific  reference  information  and  codes  from  numerous  sources. 
JFRG  can  produce  JOPES  executable  TPFDDs,  a  JOPES  transaction  file  for  modifications  to  an 
existing  OPLAN  database,  and  can  download  existing  JOPES  plans. 

2.  System  Requirements 

JFRG  operates  on  an  NT  4.0  platform. 

3.  Users/Training 

JFRG  is  utilized  by  the  joint  planning  community.  JOPES  users  are  not  anticipated  to  have 
problems  using  JFRG  and  manuals  will  be  distributed  with  the  software.  The  developer  will  train 
the  DISA  (D3)  Mobile  Training  Teams  (MTTs)  and  the  MTTs  are  to  provide  on-site  training  as 
required. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj  Cooper  (703)  735-8611. 

The  GCCS  Engineer  POC  is  Maj  Howell  (703)  735-8631. 
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Nickname,  and  Exercise  Term  system  (NICKA) 


1.  System  Description 

The  Code  Word,  Nickname,  and  Exercise  Tenn  system  (NICKA)  is  designed  to  fully  automate 
the  OSD  requirement  for  maintenance  of  code  words,  nicknames,  exercise  terms  and 
reconnaissance  nicknames  data  by  the  Joint  Staff  NICKA  maintains  records  of  all  reported  code 
words  and  their  status,  all  reconnaissance  nicknames  used  at  the  Joint  Reconnaissance  Center,  all 
exercise  terms,  and  all  currently  authorized  nicknames.  The  system  validates  code  word  and 
nickname  usage  with  assigned  agencies  and  ensures  that  authorized  nicknames  and  code  words 
are  not  duplicated.  The  NICKA  transaction  provides  a  way  to  register  and  maintain  the  currency 
of  code  words,  nicknames,  and  exercise  terms.  NICKA  uses  a  three-tiered  architecture:  client, 
server,  and  database.  The  three  segments  that  make  up  NICKA  (NICKO,  NICKCL  and 
NICKDB)  are  described  below.  NICKO  has  two  components.  One  component  provides  all 
HTML,  Java  class,  and  script  files  necessary  to  display  infonnation  to  the  users  and  accept  their 
inputs  from  a  Java-supported  web  browser.  The  other  component  is  the  server-side  application 
that  accepts  client-provided  information,  uses  it  to  query  the  database,  and  returns  the  resulting 
information  to  the  client.  The  NICKA  Online  Client  segment  (NICKCL)  is  designed  to  provide 
the  icon  for  the  user’s  GCCS  Common  Desktop  Environment  (CDE)  to  launch  the  NICKA 
Online  Web  Application.  At  the  NMCC,  each  authorized  user  must  be  entered  in  the  NICKA 
database  before  the  user  can  access  the  application  with  the  icon.  When  the  icon  is  launched,  the 
application  validates  the  user  and  the  web  browser  will  display  the  initial  entry  screen  for  which 
the  user  is  authorized  to  access  the  application.  The  initial  screen  displayed  is  based  on  the  user’s 
type:  retrieval  (R),  update  (U)  or  maintenance  (M).  The  NICKA  Database  segment 
(NICKDB)  builds  the  NICKA  Oracle  tables  and  loads  data  into  the  tables  to  support  the  NICKA 
Online  Web  Application.  This  segment  will  reside  on  the  database  server  at  the  NMCC. 

2.  System  Requirements 

NICKA  segments  are  developed  for  the  Sun/Solaris  platfonn. 

3.  Users/Training 

GCCS(T)  users  will  include  the  National  Command  Authorities  (NCA)  and  the  CINCs.  GCCS 
training  coordinator  and  NMCC  mobile  training  teams  are  currently  coordinating  training 
curriculum  and  presentation. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj.  Partridge  (703)  735-8661. 

The  GCCS  Engineer  POC  is  Jaime  Medero  (703)  681-82590. 
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Nuclear  Weapons  Contingency  Operations  Module  Server  (NWCOMS) 


1.  System  Description 

The  Nuclear  Weapons  Contingency  Operations  Module  Server  (NWCOMS)  provides 
summarized  information  regarding  the  status,  location,  and  condition  of  U.S.  nuclear  weapons. 

It  is  made  up  of  two  segments,  NWCOM  and  NWCOMS,  the  client  and  server  respectively,  and 
is  part  of  the  GCCS-T  application. 

2.  System  Requirements 

NWCOMS  is  intended  for  the  Solaris  2.5.1  Operating  System  running  on  Sun  Microsystem 
servers.  It  requires  access  to  the  SIPRNET. 

3.  Users/Training 

NWCOMS  is  used  by  Defense  Threat  Reduction  Agency  staff,  Joint  Staff  and  Unified  Command 
staffs  for  planning  and  operations  as  required. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  POC  is  Maj  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  POC  is  Jeff  Bognar,  (703)  73 
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Secret  Agent 


1.  System  Description 

Secret  Agent  3.1  is  a  file  encryption  utility  containing  implementations  of  the  most  secure  and 
popular  encryption  and  authentication  algorithms  available  today.  This  segment  is  a  partial 
segment  that  verifies  that  the  AT&T  Secret  Agent  application  has  been  installed  on  the  PC.  This 
version  adds  the  Integ  directory  (containing  the  IntegNotes  and  VSOutput  files)  and  changes  the 
$MEMORY  value  to  18  to  reflect  the  value  stated  in  the  SVD. 

2.  System  Requirements 

Secret  Agent  runs  on  the  Windows  NT  4.0  operating  system  The  segment  requires  that  the 
commercial  off-the-shelf  (COTS)  product,  AT&T  Secret  Agent,  be  installed  on  the  target 
computer  before  the  segment  is  installed.  If  the  COTS  software  is  not  installed,  the  installation 
will  be  terminated.  Individual  services  or  GCCS  sites  are  required  to  procure  licensed  copies  of 
the  AT&T  Secret  Agent  software. 

3.  Users/Training 

No  training  is  required  nor  given. 

4.  Points  of  Contact 

The  Program  Management  Office  POC  is  Major  Partridge,  (703)  735-8661. 

The  GCCS  Engineering  Office  POC  is  LCDR  Otis,  (703)  735-8764. 
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Theater  Analysis  Replanning  and  Graphical  Education  Toolkit  (TARGET) 


1.  System  Description 

TARGET  is  a  set  of  applications  designed  to  assist,  in  a  distributed  and  collaborative 
environment,  the  employment  planning  process  under  crisis  action  conditions  at  the  CJCS  and 
CINC  (strategic  and  theater/operational)  levels.  It  is  normally  included  as  part  of  the  Joint 
Planning  and  Execution  Toolkit  (JPET). 

2.  System  Requirements 

TARGET  runs  on  Solaris  and  HP  Platforms.  The  TARGET  segment  installation  requirements 
are  that  Objectivity/DB  (OBJECT)  4.0.10  and  Perl  (PERL)  5.0  are  already  installed.  Run-time 
requirements  are  that  Force  Module  Editor  (FMEDIT),  JTF  Map  System  (MATT),  Netscape 
Web  Browser  (WEBBr),  Orbix  (IT)  2.2c,  and  Applix  (AST)  must  be  installed  for  various 
TARGET  functions  to  be  useable. 

The  user  organization  will  be  responsible  for  obtaining  software  licenses  for  Orbix  2.2,  Oracle 
7.3.2  and  Applix. 

3.  Users/Training 

Sites  supporting  Joint  Staff,  Service  Headquarters,  Unified  Commands,  Joint  Task  Force 
Headquarters,  and  Service  Component  Commands  and  JPET  users,  for  crisis  action  planning  and 
collaborative  planning,  will  use  TARGET. 

4.  Points  of  Contact 

The  GCCS  Program  Management  Office  point  of  contact  is  Major  Cooper,  (703)  735-8611. 

The  GCCS  Engineer  point  of  contact  is  Bob  Marion,  (703)  735-8578. 
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The  DII  COE  (from  the  I&RTS,  v.  4.0) 


62 

The  DII  COE  originated  with  a  simple  observation  about  command  and  control  systems: 
certain  functions  (mapping,  track  management,  communication  interfaces,  etc.)  are  so 
fundamental  that  they  are  required  for  virtually  every  command  and  control  system.  Yet  these 
functions  are  built  over  and  over  again  in  incompatible  ways  even  when  the  requirements  are  the 
same,  or  vary  only  slightly,  between  systems.  If  these  common  functions  could  be  extracted, 
implemented  as  a  set  of  extensible  low-level  building  blocks,  and  made  readily  available  to 
system  designers,  development  schedules  could  be  accelerated  and  substantial  savings  could  be 
achieved  through  software  reuse.  Moreover,  interoperability  would  be  significantly  improved 
because  common  software  is  used  across  systems  for  common  functions,  and  the  functional 
capability  only  needs  to  be  built  correctly  once  rather  than  over  and  over  again  for  each  project. 

This  observation  led  to  the  development  of  the  DII  COE.  Although  its  roots  are  in  the  C4I  arena, 
the  DII  COE  and  its  principles  are  not  unique  to  C4I.  The  DII  COE  has  been  expanded  to 
encompass  a  range  of  other  functional  areas  including  logistics,  transportation,  base  support, 
personnel,  health  affairs,  and  finance.  All  new  Defense  Information  Systems  Agency  (DISA) 
systems  are  being  built  using  the  DII  COE  while  existing  DISA  systems  are  being  migrated  to 
use  the  DII  COE.  The  Office  of  the  Secretary  of  Defense  (OSD)  has  recently  issued  a  directive63 
that  requires  JTA  compliance  and,  indirectly,  use  of  the  DII  COE. 

A  significant  aspect  of  the  COE  challenge  is  to  strategically  position  the  architecture  so  as  to  be 
able  to  take  advantage  of  technological  advances.  At  the  same  time,  the  system  must  not  sacrifice 
quality,  stability,  or  functionality  already  in  the  hands  of  the  warrior.  In  keeping  with  current 
DoD  trends,  the  COE  emphasizes  use  of  commercial  products  and  standards  where  applicable  to 
leverage  investments  made  by  commercial  industry. 

A  Brief  History  of  the  DII  COE 

Initial  DII  COE  development  was  driven  by  a  near-tenn  requirement  to  build  a  suitable  World- 
Wide  Military  Command  and  Control  System  (WWMCCS)  replacement.  To  achieve  the  near- 
tenn  WWMCCS  replacement  objective,  technical  experts  and  program  managers  from  the 
Services,  intelligence  community,  Defense  Mapping  Agency  (DMA),  and  other  interested 
agencies  met  for  several  months  beginning  in  the  fall  of  1993.  Participants  proposed  candidate 
systems  as  a  possible  starting  point  for  a  COE  architecture  or  as  a  suitable  candidate  for 
providing  capabilities  to  meet  WWMCCS  replacement  requirements.  None  of  the  candidate 
systems  met  all  requirements,  but  it  was  clear  that  a  combination  of  the  “best”  from  several 
systems  could  produce  a  near-term  system  that  would  be  suitable  for  WWMCCS  replacement. 


62  The  acronyms  “DII  COE”  and  “COE”  are  used  interchangeably  throughout  this  document.  Other  COEs  have  been 
created  in  the  past  (such  as  the  Joint  Maritime  Information  System  (JMCIS)  COE),  which  were  very  similar  in 
scope  or  implementation  with  the  DII  COE.  To  avoid  confusion,  unless  otherwise  indicated,  “COE”  always  refers 
to  the  DISA  DII  COE. 

63  OSD  Directive  dated  22  August  1996  (Subject:  Implementation  of  the  DOD  Joint  Technical  Architecture).  The 
directive  states:  all  new  C4I  systems  and  other  systems  that  interface  to  C4I  systems  shall  be  in  compliance  with 
the  JTA.  The  JTA  in  turn  mandates  use  of  the  DII  COE.  The  JTA  is  being  expanded  in  scope  to  address  weapons 
systems  as  well. 
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Moreover,  an  infrastructure  could  be  put  into  place  and  a  migration  strategy  defined  to  preserve 
legacy  systems  until  migration  to  the  intended  architecture  could  be  realized. 

The  cornerstone  architectural  concept  jointly  developed  during  that  series  of  meetings  was  the 
Global  Command  and  Control  System  (GCCS)  COE.  This  initial  COE  was  limited  in  scope  to 
address  the  immediate  C4I  problem  (i.e.,  WWMCCS  replacement),  but  its  principles,  structure, 
and  foundation  deliberately  went  far  beyond  just  the  C4I  mission  domain.  The  GCCS  COE  was 
composed  of  software  contributed  from  candidate  systems  evaluated  by  this  original  Joint 
engineering  team. 

An  initial  proof-of-concept  system,  GCCS  1.0,  was  installed  in  early  1994  at  one  site  to  validate 
the  approach  and  to  receive  early  feedback.  GCCS  1.1  followed  in  the  summer  of  1994  and  was 
the  first  attempt  to  integrate  software  from  Service  programs  as  initial  GCCS  COE  components. 
GCCS  1 . 1  included  mission  applications  from  other  programs  operating  in  a  “federated”  mode. 
That  is,  the  mission  applications  were  integrated  together  so  as  to  be  able  to  run  on  the  same 
hardware  without  interfering  with  each  other,  but  not  yet  able  to  effectively  share  data  between 
applications.  GCCS  1 . 1  was  installed  and  tested  at  beta  sites  and  used  at  certain  operational  sites 
to  monitor  events  during  the  1994  Haiti  crisis.  GCCS  2.0  fielding  began  in  early  1995  at  a 
number  of  operational  sites.  GCCS  2.1  was  fielded  in  mid- 1995  and  by  mid- 1996  had 
successfully  replaced  WWMCCS.  A  prototype  version  of  GCCS  2.2  was  the  basis  for  the  1995 
Joint  Warrior  Interoperability  Demonstration  (JWID  95)  and  a  refinement  of  it  was  the  basis  for 
JWID  96.  Another  GCCS  2.2  enhancement  was  placed  in  theater  to  support  Bosnia  operations 
and  for  contingency  planning  when  tensions  in  the  Gulf  area  increased  in  mid- 1996. 

In  mid- 1995  technical  experts  met  under  DISA  guidance  to  expand  the  GCCS  COE  into  the  DII 
COE.  The  DII  COE  was  then  expanded  to  address  other  mission  domains.  Much  of  the  original 
software  has  been  updated  to  take  advantage  of  further  technological  advances  and  Commercial 
Off-the-Shelf  (COTS)  software  has  replaced  some  of  the  original  Government  Off-the-Shelf 
(GOTS)  components.  From  this  historical  perspective,  the  GCCS  COE  can  be  viewed  as  a  subset 
of  the  much  larger  DII  COE.  Although  GCCS  succeeded  in  replacing  the  aged  WWMCCS,  it  is 
important  to  realize  that  GCCS  is  far  more  than  just  a  WWMCCS  replacement. 

In  1996,  the  Air  Force  Electronic  Systems  Command  (ESC)  at  Hanscom  AFB  began  exploring 
the  applicability  and  viability  of  DII  COE  concepts  to  real-time  systems.  In  the  spring  of  1997, 
based  upon  exploratory  work  begun  at  ESC,  representatives  from  the  Air  Force,  Army,  and  Navy 
met  to  discuss  the  high  correlation  of  real-time  requirements  across  the  services.  In  July  1997, 
the  Air  Force,  Army,  Navy,  and  Marine  Corps  jointly  petitioned  DISA  to  charter  a  DII  COE 
Real-time  Technical  Working  Group  (TWG).  The  objective  of  the  TWG  would  be  to  develop  a 
set  of  common  requirements  and  recommendations  for  potential  products  to  provide  real-time 
capabilities,  thus  expanding  the  scope  of  the  DII  COE  to  include  real-time  systems.  DISA 
approved  the  Services’  request,  and  the  Real-time  TWG  began  meeting  in  August  1997.  It  is 
anticipated  that  real-time  services  will  be  included  in  release  5.0  of  the  DII  COE,  and  will  be 
included  in  the  next  major  release  of  the  I&RTS. 

The  DII  COE  has  its  roots  in  command  and  control,  but  the  principles  and  implementation 
described  in  this  document  are  not  unique  to,  nor  limited  to,  command  and  control  or  logistics 
applications  but  are  readily  applicable  to  many  other  application  areas.  The  specific  software 
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components  selected  for  inclusion  in  the  COE  determine  the  mission  areas  that  the  COE  can 
address. 

The  DII  COE  Concept 

The  DII  COE  concept  is  a  new  approach  that  is  much  broader  in  scope  than  software  reuse.  Most 
software  reuse  approaches  to  date  have  proven  less  than  satisfactory.  Reuse  approaches  have 
generally  emphasized  the  development  of  a  large  software  repository  from  which  designers  may 
pick  and  choose  modules  or  elect  to  rebuild  modules  from  scratch.  It  is  not  sufficient  to  have  a 
large  repository,  and  too  much  freedom  of  choice  leads  to  interoperability  problems  and 
duplication  of  effort.  This  rapidly  negates  the  advantages  of  software  reuse. 

Software  reuse  strategies  have  also  ignored  the  importance  of  data  reuse.  The  approach  has 
traditionally  been  to  encapsulate  data  into  a  relational  database  from  which  applications  may 
retrieve  the  data  according  to  their  own  view  (i.e.,  schema).  While  this  approach  was  a 
tremendous  advance,  it  fell  short  of  the  goal  of  providing  truly  interoperable  systems  in  the  Joint 
arena.  What  is  required  is  an  approach  that  promotes  data  sharing  within  systems  and  between 
systems.  The  approach  must  also  recognize  and  resolve  the  issues  of  duplicative  data, 
inconsistencies  in  the  data,  and  data  replication.  The  Shared  Data  Engineering  (SHADE) 
component  is  the  data  reuse  strategy  for  the  DII  COE. 

The  DII  COE  emphasizes  both  software  reuse  and  data  reuse,  and  interoperability  for  both  data 
and  software.  But  its  principles  are  more  far-reaching  and  innovative.  The  COE  concept 
encompasses: 

•  An  architecture  and  approach  for  building  interoperable  systems 

•  A  minimal  but  extensible  security  architecture  and  a  set  of  security  services 

•  an  environment  for  sharing  data  between  applications  and  systems 

•  An  infrastructure  for  supporting  mission-area  applications 

•  A  rigorous  definition  of  the  runtime  execution  environment 

•  A  reference  implementation  on  which  systems  can  be  built 

•  A  collection  of  reusable  software  components  and  data 

•  A  rigorous  set  of  requirements  for  achieving  DII  compliance64 

•  An  automated  toolset  for  enforcing  COE  principles  and  measuring  DII  compliance 

•  An  automated  process  for  software  integration 

•  An  approach  and  methodology  for  software  and  data  reuse 

•  A  set  of  Application  Program  Interfaces  (  APIs)  for  accessing  COE  components 

This  document  is  an  engineering  specification  that  describes  how  modules  must  interact  in  the 
target  system.  System  architects  and  software  developers  retain  freedom  in  building  the  system, 
but  runtime  environmental  conflicts  and  data  conflicts  are  identified  and  resolved  through 
automated  tools  that  enforce  COE  principles.  An  important  side  effect  is  that  traditional 
integration  tasks  largely  become  the  responsibility  of  the  developer.  Developers  are  required  to 


64  The  term  “DII  compliance”  is  preferred  instead  of  “COE  compliance”  and  is  used  throughout  the  I&RTS.  The 
compliance  concept  and  approach  has  not  changed,  but  compliance  is  measured  for  segments  within  the  COE  as 
well  as  mission-application  segments  that  lie  outside  the  COE.  Therefore,  “DII  compliance”  is  more  descriptive 
and  correct  than  “COE  compliance.” 
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integrate  and  test  their  software  with  the  COE  prior  to  delivering  it  to  the  government.  This 
simplifies  integration  because  those  who  best  understand  the  software  design  (the  original 
developers)  perform  it,  it  reduces  the  cost  because  integration  is  performed  earlier  and  at  a  lower 
level  in  the  process,  and  it  allows  the  government  to  concentrate  on  validation  instead  of 
integration. 

The  COE  must  be  understood  as  a  multi-faceted  concept.  Understanding  how  the  many  facets 
interact  is  important  to  appreciate  the  scope  and  power  of  the  DII  COE  and  to  avoid  confusion  in 
understanding  COE  material.  The  next  subsections  deal  with  four  specific  facets  in  more  detail: 

•  The  COE  as  a  system  foundation 

•  The  COE  as  an  architecture 

•  The  COE  as  a  reference  implementation 

•  The  COE  as  an  implementation  strategy 

Failure  to  understand  these  facets  will  lead  to  confusion  and  non-compliant  systems. 

The  DII  COE  as  a  System  Foundation 

The  DII  COE  is  not  a  system;  it  is  a  foundation  for  building  systems.  Figure  6G-1  is  a  simplified 
diagram  that  shows  how  the  DII  COE  serves  as  a  foundation  for  building  multiple  systems. 
Details  such  as  specific  COE  components,  databases,  and  the  internal  structure  of  the  COE  have 
been  omitted  for  clarity.  Chapter  2  provides  this  level  of  information  and  describes  the  COE  in 
much  more  detail.  The  purpose  of  Figure  6G-1  is  to  introduce  the  concept. 

The  large  outennost  shaded  box  in  Figure  6G-1  shows  two  types  of  reusable  software:  the 
operating  system  and  COE  components.  For  the  present  discussion,  it  is  sufficient  to  note  that 
COE  components  are  accessed  through  APIs  and  that  the  COE  components  form  the 
architectural  backbone  of  the  target  system.  The  API  is  the  means  through  which  a  system 
pennits  a  programmer  to  develop  applications  through  interaction  with  the  underlying  COE. 
Standards  ( POSIX  [Portable  Operating  System  for  Information  Exchange ]  in  the  diagram)  and 
specifications  ( TAFIM  [ Technical  Architecture  Framework  for  Information  Management ],  JTA 
[Joint  Technical  Architecture ],  I&RTS  [Integration  and  Runtime  Specification ],  and  User 
Interface  Specification  [UIS]  in  the  diagram)  dictate  how  COE  components  are  to  be  built  and 
how  external  components  must  be  built  to  be  compliant  with  the  COE  architecture. 
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COE  Based  Systems 
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Figure  6G-1.  Dll  COE  and  COE-Based  Systems 


Building  a  target  system  includes  combining  COE  components  with  mission-specific  software. 
The  COE  infrastructure  manages  the  flow  of  data  through  the  system,  both  internally  and 
externally.  Mission-specific  software  is  mostly  concerned  with  requesting  data  from  the  COE 
and  then  presenting  it  in  a  form  that  is  most  meaningful  to  the  operator  (e.g.,  as  a  pie  chart,  in 
tabular  form,  as  a  graph).  The  COE  provides  the  necessary  primitives  for  such  data  whether  it  is 
stored  locally,  or  whether  it  is  accessed  remotely  across  a  Local  Area  Network  (LAN)  or  Wide 
Area  Network  (WAN).  This  frees  the  system  designer  to  concentrate  on  meaningful  data 
presentation  and  not  on  the  mechanics  of  data  manipulation,  network  communications,  database 
storage,  etc. 

There  is  only  one  COE  regardless  of  the  target  system.  The  COE  is  a  set  of  building  blocks. 
System  designers  select  those  building  blocks  (e.g.,  COE  components)  required  for  their  mission 
application,  while  excluding  building  blocks  that  are  not  required.  Each  derived  system  uses  the 
same  set  of  APIs  to  access  common  COE  components,  the  same  approach  to  integration,  and  the 
same  set  of  tools  for  enforcing  COE  principles.  For  common  functions  (e.g.,  communications 
interfaces,  dataflow  management),  each  target  system  uses  precisely  the  same  COE  software 
components.  Compliant  systems  do  not  implement  their  own  versions  of  algorithms  within  the 
COE  because  this  will  rapidly  lead  to  interoperability  problems  as  algorithms  are  interpreted 
differently  or  because  systems  fail  to  upgrade  algorithms  at  the  same  time.  This  approach  to 
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software  reuse  significantly  reduces  interoperability  problems  because  if  the  same  software  is 
used,  it  is  not  possible  to  have  two  systems  that  interpret  or  implement  standards  differently. 

The  DII  COE  as  an  Architecture 

The  DII  COE  is  a  network-centric65  “plug  and  play”  open  architecture,  presently  designed  and 
implemented  around  a  client/server  model.  Functionality  is  easily  added  to  or  removed  from  the 
target  system  in  small  manageable  units  called  segments.  Segments  are  defined  in  terms  of 
functions  that  are  meaningful  to  operators,  not  in  terms  of  internal  software  structure.  Structuring 
the  system  into  segments  in  this  manner  allows  flexibility  in  configuring  the  system  to  meet 
specific  mission  needs  or  to  minimize  hardware  requirements  for  an  operational  site.  Site 
personnel  perform  field  updates  by  replacing  affected  segments  through  use  of  a  simple, 
consistent,  graphically  oriented  user  interface. 

The  DII  COE  model  is  analogous  to  the  Microsoft  Windows®  paradigm.  The  idea  is  to  provide  a 
standard  environment,  a  set  of  standard  off-the-shelf  components,  and  a  set  of  programming 
standards  that  describe  how  to  add  new  functionality  to  the  environment.  The  Windows 
paradigm  is  one  of  “federation  of  systems”  in  that  properly  designed  applications  can  coexist  and 
operate  in  the  same  environment.  But  simple  coexistence  is  not  enough.  It  must  be  possible  for 
applications  to  share  data.  The  DII  COE  extends  the  Windows  paradigm  to  allow  for  true 
“integration  of  systems”  in  that  mission  applications  share  data  at  the  server  level. 

Federation  versus  integration  is  an  important  architectural  distinction.  However,  integration  is 
not  possible  without  strict  standards  that  describe  how  to  properly  build  components  to  add  to  the 
system.  This  applies  equally  to  software  functions  and  data.  This  document  and  other  related 
documents  detail  the  technical  requirements  for  a  well-behaved,  Dll-compliant  application.  The 
COE  provides  automated  tools  to  measure  compliance  and  to  pinpoint  problem  areas.  A  useful 
side  effect  of  the  tools  and  procedures  is  that  software  integration  is  largely  an  automated 
process,  thus  significantly  reducing  development  time  while  automatically  detecting  potential 
integration  and  runtime  problem  areas. 

More  precisely,  to  a  developer  the  DII  COE  includes  each  of  the  following: 

•  An  Architecture66:  A  precisely  defined  TAFIM  and  JZT-compliant  architecture  for  how  system 
components  will  interact  and  fit  together  and  a  definition  of  the  system-level  interface  to  COE 
components. 

•  A  Runtime  Environment:  A  standard  runtime  operating  environment  that  includes  “look  and 
feel,”  operating  system,  and  windowing  environment  standards.  Since  no  single  runtime 
environment  is  possible  in  practice,  the  COE  architecture  provides  facilities  for  a  developer  to 
extend  the  environment  in  such  a  way  as  to  not  conflict  with  other  developers. 


65  The  COE  is  truly  network-centric  in  its  design  and  current  implementation.  Fielded  COE-based  systems  are 
typically  designed  to  take  advantage  of  this  fact.  However,  additional  development  is  required  to  provide  all  the 
tools  that  would  be  useful  to  fully  support  a  network-centric  system. 

66  The  JTA  describes  three  types  of  architectures:  operational,  technical,  and  system.  The  DII  COE  is  relevant  to  all 
three  types  but  does  not  and  cannot  provide  a  complete  architectural  definition  for  all  three  types.  For  example, 
the  operational  architecture  also  includes  consideration  of  the  command  echelon  and  reporting  structure.  This  is 
dictated  by  policy  and  is  thus  outside  the  scope  of  the  COE.  The  DII  COE  is  limited  to  addressing  those  aspects 
of  an  architecture  that  can  be  implemented  in  hardware  and  software  as  dictated  by  higher  level  standards, 
concept  of  operations,  and  service  doctrine. 
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•  A  Data  Environment:  A  standard  data  environment  that  prescribes  the  rules  whereby 
applications  can  share  data  with  other  applications. 

•  A  Reference  Implementation:  A  clearly  defined  set  of  already  implemented,  reusable  functions. 
A  set  of  reusable  software  and  data  is  a  cornerstone  of  the  DII  COE  product. 

•  A  Set  of  APIs:  A  collection  of  interfaces67  for  accessing  COE  components.  Thus,  the  COE  is  a 
set  of  building  blocks  in  the  same  sense  that  X  Windows  and  Motif  are  building  blocks  for 
creating  an  application’s  Graphical  User  Interface  (GUI). 

•  A  Set  of  Standards  and  Specifications:  A  set  of  rules  that  describe  how  to  use  the  COE,  how  to 
construct  segments,  how  to  create  a  GUI,  etc. 

•  A  Development  Methodology:  A  process  for  developing,  integrating,  and  distributing  the  system 
and  a  process  for  sharing  components  with  other  developers.  The  COE  emphasizes  and 
encourages  incremental  development  that  has  the  advantage  of  quickly  producing  usable 
functionality. 

The  DII  COE  as  a  Reference  Implementation 

The  COE  necessarily  includes  an  implementation  of  the  components  defined  to  be  in  the  COE. 
The  reference  implementation  is  the  key  to  reusability  and  interoperability.  Use  of  the  reference 
implementation  provided  is  required  to  assure  interoperability  and  is  therefore  a  fundamental 
requirement  for  DII  compliance.  The  reference  implementation  may  change  over  time  to  take 
advantage  of  new  technologies  or  to  fix  problem  reports,  but  improvements  are  introduced 
incrementally  while  preserving  product  stability. 

The  term  reference  implementation  should  be  properly  understood  in  the  context  of  the  DII  COE. 
It  means  that  a  single  body  of  code  has  been  used  as  a  starting  point  for  implementing  the  COE 
on  a  specific  hardware  platform  and  operating  system.  The  only  differences  in  the  actual 
executable  binary  code  are  those  that  arise  purely  as  a  result  of  porting  from  one  platform  to 
another.  The  algorithms  and  the  way  the  algorithms  are  implemented  are  identical  from  platform 
to  platform. 

The  DII  COE  as  an  Implementation  Strategy 

The  COE  is  also  an  evolutionary  acquisition  and  implementation  strategy.  This  represents  a 
departure  from  traditional  development  programs.  It  emphasizes  incremental  development  and 
fielding  to  reduce  the  time  required  to  put  new  functionality  into  the  hands  of  the  warrior,  while 
not  sacrificing  quality  nor  incurring  unreasonable  program  risk  or  cost.  This  approach  is 
sometimes  described  as  a  “build  a  little  -  test  a  little  -  field  a  lot”  philosophy.  It  is  a  process  of 
continually  evolving  a  stable  baseline  to  take  advantage  of  new  technologies  as  they  mature  and 
to  introduce  new  capabilities.  But  the  changes  are  done  one  step  at  a  time  so  that  the  warfighters 
always  have  a  stable  baseline  product  while  changes  between  successive  releases  are  perceived 
as  slight.  Evolutionary  development  has  become  a  practical  necessity  for  many  development 
programs  because  the  traditional  development  cycle  time  is  longer  than  the  technical 
obsolescence  cycle  time.  This  approach  allows  program  managers  the  option  of  taking  advantage 
of  recently  developed  functions  to  rapidly  introduce  new  capabilities  to  the  field,  or  of 


67  The  term  “API”  is  used  in  the  DII  COE  context  to  refer  to  any  well-defined  interface  between  components.  It  may 
refer  to  a  C  function  call,  a  data  file  format,  a  callable  executable  program,  etc. 
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synchronizing  with  COE  development  at  various  points  for  those  situations  where  incremental 
upgrades  are  not  readily  acceptable  to  the  customer  community. 

The  COE  implementation  strategy  is  carefully  structured  to  protect  functionality  and  data 
contained  in  legacy  systems  so  that  over  time  they  can  migrate  to  full  COE  utilization.  Legacy 
systems  must  use  only  “public”  APIs  and  migrate  away  from  use  of  “private”  APIs.  Public  APIs 
are  those  interfaces  to  the  COE  that  will  be  supported  for  the  life  cycle  of  the  COE.  Private  APIs 
are  those  interfaces  that  are  supported  for  a  short  period  of  time  to  allow  legacy  systems  to 
migrate  from  unsanctioned  to  sanctioned  APIs.  All  new  development  is  required  to  use  only 
public  APIs  and  use  of  any  other  APIs  results  in  a  non-DII  compliant  segment. 

From  the  perspective  of  a  system  developer,  whether  developing  a  new  application  or  migrating 
an  existing  one,  the  present  DII  COE  implementation  is  an  open  client/server  architecture  that 
offers  a  collection  of  services  and  already-built  modules  for  mission  applications.  Thus,  the 
developer’s  task  is  to  assemble  and  customize68  existing  components  from  the  COE  while 
developing  only  those  unique  components  that  are  specific  to  particular  mission’s  requirements. 
These  additional  mission-unique  components  must  still  adhere  to  the  standards  specified  in  the 
JTA  and  this  document.  In  many  if  not  most  cases,  this  amounts  to  adding  new  “pull-down  menu 
entries  and  icons.” 

Lessons  Learned 

The  COE  as  the  embodiment  of  an  architectural  concept  offers  the  opportunity  to  leverage  a 
mature,  proven,  field-tested  software  base  for  a  wide  variety  of  applications  for  the  services, 
agencies,  and  Joint  community.  As  budgets  shrink  and  as  budgetary  priorities  shift,  program 
managers  require  the  ability  to  continue  to  respond  rapidly  with  systems  that  satisfy  the 
information  needs  of  United  States  and  Allied  Anned  Forces.  The  COE  implementation  strategy 
is  a  significant  advancement  in  fulfilling  this  ongoing  need. 

Examination  of  state-of-the-art  development  in  light  of  these  realities  results  in  a  set  of 
fundamental  tenets  that  greatly  influence  the  history,  future,  and  direction  of  the  DII  COE.  An 
explanation  of  these  tenets  is  useful  in  understanding  the  COE  as  a  whole. 

•  Pre-COE  practices  lead  to  development  and  redevelopment  of  the  same  functionality  across 
systems.  Redevelopment  is  frequently  necessary  because  of  technological  changes  as  algorithms 
are  improved  or  as  hardware  becomes  faster  and  cheaper.  However,  development  cost  tends  to  be 
high  due  to  a  lack  of  coordination  between  programs  that  share  common  requirements. 

•  Security  must  be  designed  into  the  architecture.  The  increasing  importance  placed  upon 
system  security  has  underscored  the  need  to  view  security  as  an  engineering  discipline.  Security 
considerations  must  be  addressed  throughout  the  entire  system  life  cycle  from  requirements 
analysis  through  maintenance.  It  is  not  sufficient  to  “add  security”  after  fielding  or  even  after 
development. 

•  Duplication  of  functionality  within  the  same  system  is  more  expensive  than  avoiding 
duplication.  Lack  of  coordination  between  program  developers  is  a  fundamental  cause  for 


68  Customization  is  achieved  in  two  ways:  by  omitting  COE  components  that  are  not  required  and  by  configuring 
operational  characteristics  of  the  selected  COE  components.  Customization  does  not  mean  the  ability  to  change 
the  functional  operation  of  the  component  (a)  outside  the  configurable  items  provided  by  the  component  or  (b) 
outside  the  facilities  provided  by  the  component’s  APIs.  When  customizing  the  COE  is  discussed  in  this 
document,  it  must  be  understood  in  this  context  as  a  way  of  tailoring  the  COE  to  meet  a  specific  mission  need. 
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duplicative  functions,  but  an  additional  factor  is  that  reuse  libraries  are  not  commonly  available. 
The  impact  of  duplication  is  more  than  just  program  costs.  When  functionality  is  duplicated, 
system  users  are  often  given  conflicting  information  even  in  the  presence  of  identical  data 
because  designers  took  slightly  different  approaches  to  solving  the  same  problems  or  made 
slightly  different  assumptions. 

•  Interoperability  is  not  achievable  through  “paper”  standards  alone.69  Standards  are 
necessary,  but  not  sufficient,70  to  guarantee  interoperability.  Interoperability  problems  are 
generally  not  caused  by  the  standards  chosen  but  by  differing  or  incorrect  interpretations  of 
standards.  System  designers  often  choose  different  standards  with  which  to  comply,  but  even 
when  the  standards  are  the  same,  different  interpretations  of  the  standards  can  greatly  change  the 
way  the  resulting  system  operates.  The  COE  emphasizes  use  of  industry  and  government 
standards,  but  relies  even  more  on  automated  ways  of  measuring  and  evaluating  compliance,  and 
thus  quantitatively  evaluating  program  risk.  The  only  practical  way  to  achieve  interoperability  is 
to  use  exactly  the  same  software,  written  to  appropriate  standards,  for  common  functions  across 
applications.  For  example,  the  COE  contains  a  common  tactical  track  correlator  to  ensure  that  all 
users  see  the  same  tactical  picture.  The  answer  produced  by  the  correlator  may  be  incorrect  but  a 
problem  correction  in  one  place  then  becomes  effective  for  all  users. 

•  Pre-COE  practices  lead  to  exponential  growth  in  testing  and  associated  development  costs. 
Lack  of  commonality  and  modularity  in  system  building  blocks  means  that  there  is  much 
duplication  of  effort  in  testing  basic  functionality  and  testing  in  one  section  of  a  system  is  often 
tightly  coupled  to  testing  in  another  section.  This  complicates  and  extends  the  certification 
process.  Configuration  management,  system  integration,  and  long-term  maintenance  are  also 
more  complex  and  costly  when  there  is  a  lack  of  commonality  and  modularity  in  system  building 
blocks. 

•  The  importance  of  training  is  usually  underestimated  and  the  magnitude  of  the  training 
problem  is  increasing.  An  operator  is  often  expected  to  use  multiple  systems  that  behave 
completely  differently,  are  equally  complex  with  their  own  subtleties,  and  that  give  slightly 
different  answers.  Operator  turnover  is  rapidly  reaching  the  point  where  the  time  it  takes  to  train 
an  operator  is  a  significant  portion  of  the  time  that  the  operator  is  assigned  to  his  current  tour  of 
duty.  Training  is  greatly  reduced  by  a  consistent  “look  and  feel”  and  by  the  ability  to  present  to 
the  operator  only  those  functions  useful  for  the  task  at  hand. 

•  Don’t  reinvent  the  wheel.  If  a  component  already  exists,  it  should  probably  be  utilized  even  if 
the  component  is  not  the  optimum  solution.  Almost  any  module  can  be  improved  but  that  is  rarely 
the  issue.  Reuse  of  existing  and  proven  software  and  data  structures  allow  focus  of  attention  on 
mission  uniqueness.  Rather  than  concentrating  scarce  development  resources  on  recreating 
building  blocks,  the  resources  can  be  more  appropriately  applied  to  configuration  and 
development  of  functionality  and  data  structures  that  are  not  already  available. 

•  Utilize  existing  commercial  standards,  specifications,  and  products  whenever  feasible.  The 

commercial  marketplace  generally  moves  at  a  faster  pace  than  the  military  marketplace  and 
advancements  are  generally  available  at  a  more  rapid  rate.  Use  of  commercial  products  has 
several  advantages.  Using  already  built  items  lowers  production  costs.  The  probability  of  product 
enhancements  is  increased  because  the  marketplace  is  larger.  The  probability  of  standardization  is 
increased  because  a  larger  customer  base  drives  it. 


69  This  statement  is  not  meant  to  minimize  the  importance  of  standards,  but  to  state  that  they  alone  are  not  sufficient 
to  solve  interoperability  problems.  The  situation  would  be  far  more  desperate  in  the  absence  of  standards. 

70  The  solution  provided  by  the  COE  is  to  define  specifications  and  a  reference  implementation  of  a  standard.  For 
example,  in  the  user  interface  area,  Motif  is  the  standard  selected  for  UNIX  platforms  and  the  User  Interface 
Specifications  for  the  DII  is  the  specification  written  to  be  compliant  with  Motif,  but  tailored  for  the  particular 
mission  domain. 
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Requirements  and  Objectives 

The  following  requirements  apply  to  the  DII  COE: 

•  The  DII  COE  will  be  fully  compliant  with  the  JTA71.  Standards  defined  within  the  JTA  promote 
an  open  systems  architecture,  the  benefits  of  which  are  assumed  to  be  well  known  and  generally 
accepted. 

•  The  DII  COE  is  intended  to  be  hardware  independent  and  operate  on  a  range  of  open  systems 
platforms  running  under  standards-based  operating  systems.  Program-driven  requirements, 
associated  testing  costs,  and  funding  will  dictate  which  specific  hardware  platforms  are  given 
priority. 

•  Non- developmental  items  (NDIs),  including  both  COTS  and  GOTS  products,  are  the  preferred 
implementation  approach. 

•  The  DII  COE  is  programming- language  neutral.  It  does  not  state  a  preference  of  one  language 
over  another,  but  leaves  the  selection  of  a  programming  language  to  higher-level  standards  profile 
guidance  and  programmatic  considerations.  Any  statements  in  the  I&RTS  which  appear  to  state 
or  imply  a  preference  for  one  language  over  another  are  unintentional. 

COE  development  is  driven  by  C4I  for  the  warrior  requirements  as  articulated  by  the  services 
through  the  appropriate  DISA  Configuration  Control  Board  (CCB)  process.  Development 
priorities  are  established  by  the  CCB  Chair  and  given  to  the  DII  COE  Chief  Engineer  for 
implementation. 

The  broad  program  drivers  for  the  DII  COE  lead  to  a  number  of  program  objectives  that  include 
those  stated  in  the  TAFIM,  Volume  2\ 

•  Commonality:  Develop  a  common  core  of  software  that  will  form  the  foundation  for  Joint 
systems,  initially  for  C4I  and  logistics  systems. 

•  Reusability:  Develop  a  common  core  of  software  that  is  highly  reusable  to  leverage  the 
investment  already  made  in  software  development  across  the  services  and  agencies. 

•  Standardization:  Reduce  program  development  costs  through  adherence  to  industry  standards. 
This  includes  use  of  commercially  available  software  components  whenever  possible. 

•  Engineering  Base:  Through  standardization  and  an  open  architecture,  establish  a  large  base  of 
trained  software/systems  engineers. 

•  Training:  Reduce  operator  training  costs  and  improve  operator  productivity  through  enforcement 
of  a  uniform  human-machine  interface,  commonality  of  training  documentation,  and  a  consistent 
“look  and  feel.” 

•  Interoperability:  Increase  interoperability  through  common  software,  common  data  structures, 
and  consistent  system  operation. 

•  Scalability:  Through  use  of  the  segment  concept  and  the  COE  architectural  infrastructure, 
improve  system  scalability  so  that  COE-based  systems  will  operate  with  the  minimum  resources 
required. 

•  Portability:  Increase  portability  through  use  of  open  systems  concepts  and  standards.  This  also 
promotes  vendor  independence  for  both  hardware  and  software. 


71  JTA  replaces  some  of  the  standards  guidance  in  the  TAFIM  as  per  OSD  directive  (Subject:  Implementation  of  the 
DOD  Joint  Technical  Architecture)  dated  22  August  1996.  It  replaces  those  standards  for  service  areas  defined 
within  the  JTA.  For  those  service  areas  not  included  in  the  JTA,  guidance  in  Volume  7  of  the  TAFIM  is  to  be 
followed. 
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Security:  Improve  system  security  to  the  extent  possible  to  protect  the  system  from  deliberate 
attack  and  prevent  unauthorized  access  to  data  and  applications. 

Testing:  Reduce  testing  costs  because  common  software  can  be  tested  and  validated  once  and 
then  applied  to  many  applications. 
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Appendix  6H 

GCSS-AF  The  Way  Ahead  (Volume  1) 


The  Way 

ahead 


eport  prepared  for  the  Chief 
matJon  Officer  USAF.  by  the 
Combat  Support  Systcm-AF 


Requirements  Integration  Tiger 


Team,  31  August  1999 
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GCSS-AF  will  provide  the 

and  supporting 
elements  with 

,  with  the 

appropriate  level  of  security, 
needed  fo rthe  Expeditionary 
Aerospace  Force  to  "execute  the 
Air  Force  Mission  throughout 
the  ^  of  military 

operatioias.  —  - 
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* . ,  The  success  of  the  Expeditionary  Aerospace  Force 
ultimately  will  rest  on  the  Air  Force's  ability  to  sustain  it, 
Agile  Combat  Support  provides  commanders  improved 
responsiveness,  mobility,  and  sustainability  of  their 
forces 

xL.  Information  technologies,  such  as  the  Global  Combat 
Support  System,  featuring  both  new  leading-edge 
capabilities  and  technical  refreshment  of  existing 
systems,  arc  hey  to  Agile  Combat  Support . _ 

— OfflWii/  \fk'hnet  Ajffln 

t'hkfiif  Staffs  United  Stales  Air  Farce 


— Utmnmhle  F.  Whitten  Peters 
Secretary  af  r fie  Air  Farce 
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AF 


The  to  implement  the 

recommendations.  The  EAF  concept 
depends  on  an  i  ntegrated  GCSS-Af . 
The  Chief  Information  Officer  can 
provide  the  appropriate  impetus,  and 
technology  is  new  an  enabler  rather 
lhan  a  timing  factor. 
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The  tilled  Information  Officer  {ClQ|  gavo  the  Global  Combal  Gupporl  Gystom 
AirForco^GCSG  AF>Ftoqisiromcnts  Integration  Tiger  Tonm  i|GRITT)a  tough, 
bul  important,  task  develop  an  rd  eg  rated  requrements  process  thal  will 
ensure  a  slrcng  and  successful  GCSS  AF.  Tho  lash  is  tough  because  it  requires 
□grcemonl  among  various  tunclinnal  organisations  to  adept  an  enterprise-  view  cf 
combat  support  inlormalion.  T  ho  lash  is  importanl  because  I  ho  Expedilionary 
Aerospace  Force  (EftF)  coieopl  roisos  on  integrated  svMcirs  that  p'wdc  liirt-lv, 
a cc ij rale  and  truslc-d  nlornirst  or  to  the  deployed  Ar  Expeditionary  Force  (AEF) 
commandor  across  the  spectrum  at  mf  Mary  operations 
We  worked  the  problem  hard  -lodicalcd  subjocl  matter  experts  peeled  Ihon 
colfcpdivc  aiqocncnoo  to  preside  the  roco  mmond  at  ions  m  this  report.  Each  certnbuled 
to  the  hnal  product  each  should  bo  proud  cH  lhal  contribution 
Tha  com  tot  support  pro  cess  has  evoked  throughout  thra  years  w:t  mar/  ftJ>ctional 
a  gar  ral  ers  providing  apoeoot  aver/larqe  entorpnse.  FunclionaJ  oommumlres  are 
performing  quality  work  to  improve  thnr  processes  and  modernize  thr:ir  systems.  A'hto 
cvcryano  supports  I  ho  road  for  in  log  rated  mlormaton  to  support  the  waffigtar,  the 
different  orqanizaliorial  alternatives  were  appcalng  m  varvng  degrees  to  vanous 
agendas  tt  was  impossible  to  l:ul:l  unanimous  agrocmerd  for  cur  roeom merrd aliens— 
consensus  was  difficult  but  achievable. 

We  bclovo  Iho  lime  phased  approach  recommended  presides  tie-  bcsl  afcemalrvo 
for  admcn.inq  the  vison  oi  a  GCGG  AF  capable  of  support ng  EAF  deployments  ard 
operations  In  thpj  near  term  wc  bcliove  a  □iroctorior  GCGG  AF  and  EBf C  is  required 
tobc^nimp+cmcnlalignoflhc  rcc  cm  m  end  a  I  ion  s .  U  Hm  a  I  c  k  vm  believe  thpa  ir'crcspa:o 
Command  and  Centro!  intelligence,  Gurveillanoe,  and  Reconnaissance  Center 
(A£2fSRC|  should  load  this  effort  for  our  Air  Force  because  oi  Ms  warlighling  Ice  us 
cxponerco  with  cxpcrimentalien,  and  Iho  inexpiable  integration  between  Iho  Global 
Command  and  Control  Syslcir  (IjGCS-i  ana  CCS&  Our  rocommtrtdatnn  Jul  y  supports 
Ihe  .so  il  GCS-£  program  and  postures  the  Air  Force  to  be  a  leader  in  oombal  support 
ssstoms  development 

—BUD  BELL,  Brig  I L$AF 

f’/jp ef,  Gt  'SS-AF  Requirements 
futegratinn  Tigw  Team  f&RfTT) 
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NoHhor  our  timlmm  piwmmm  nor  our 


Information  systems  ire  veraodll  enough  to 
mecommodf  the  Information  donwilt 


spgwnsd  by  tho  uncortabiUss  of  war.  GCSS- 
AF  allows  ua  to  mUgita  thna  shortBomli^i. 
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Tlw  Air Force  v.  irf ighrerinr.nl  he 
able  to  co  menu  ni  ljI*  and 
UMmalcIc  i;:  !■  r:n..:i*  >ii  rapidly. 
Ihjri  I  nleciUkilLOL  l!1.. il  be  lillV-lv .  KDliralC, 
.1  iv.l  i  ■  ii  {l-j-,1  lo  enable  conanuuJeri  lo 
shape  ami  define  ihe  luMlo  space'  tv»i  h 
canfiilence.  Iheiparngf:mgco.miiYmders 
□nisi  hive  mil-time'  visibjluy  ed  re  levin 
Age  L‘  L'cenhic  Support  (ACS|  infotnulbon 
farhelh  m-gurjiscni  iinH  deployed  farces, 
□sii  ling lliL-rn  Ki  perform  IheiropeuJ^naJ 
mission  nl  iny  Jour  ion  l\d  or  stove  the 
gl'>he.  The-  LnlecimlLon  must  meel  iIil- 
oeeiLs  of  iLe  S-ecrel.inil.  Alt  farce' 
fund  iiai.il  areas.  and  commanders- sc  jU 
Leve-Js  ■aliLle  eniurn.  mg,  Lheir  leadership 
raLe. 


A  preiperK  dud  ;neJ  titSS-Al' 
sh %l lti i  'Mil  ji j>:-i  ide  : 1 1 1 1 ■  r i ij : 1 1 i ■> 1 1 
lb, il  is  LLciluIy,  jeturate,  iirnl 
InutEcii. 


j  lie  eurreni  syslemj  developed  for  Che 
Cold  Wnr  iiihilnL  successful  AEF 
operations.  The- enrrcn.1  information 
pie^i-ssei  supported  liy  iLese  system^  ire 
loo  complex,  fncme'nled.  and  slew  la 
meel  wvirijghlcr  ueuiLs  e-ffeclLveLy  imL 
efficiently  We  need  la  un  prove  how  we 
gene  role,  maintain.  ih.ire.  porlmy.  ami  use 
■Lila.  For  eaeli  ilemofriv1alh.il  is- captured, 

I  he  re  m  nil  heo  single  airilionljljve source 
far  use  I : y  holh  fund-ionnl  .in. I  vTirfiphler 
processes.  lo  meet  the  vision.  efTci.1i.ve 
processes  mu  si  be  LmplerienLed  and 
ledmek'CieaJ  .hi* 1,  maaes  iiicorpawed  inlo 
our  eurreni  systems. 
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AUJUI^E-'ORit'l-.  upefilikuM  Iriknumi  pj-niUk1  imdylil  Jnkour 
Ldck«f  llntely,  dHardle.  uid  Irusled  iii:  >i.mmiI  >n.  Par  L-xiiiiple, 
■lir'iaghviu  cbe-  lilyk-l  Id-l-i  I  l-frlftlrflhi.-  dir  cun  p«  ly.ru  wl-  eipen&d 
ti  lii  v.'.1  hiinil  '.  i- 1 •  I  f > i  >.-/ 1 h I ■  > 1 1  i ^ _ M >J  niim  Il  k-in.  Ike-  wej'tly.h  k-r 
diked  [he  bcllniri  hi:-,  i| ueiJiidu : 

*  1 1  uyt  muiy  preckhxn -guided  mimdliiiu  do  iw  hawiii  if*nrf! 

■  Wheiv  j  re  ihry  JkikJ — whi  cm  Ibey  mm? 

1  tMijI  b.  [Iir-li  - 1  -L :  1 1  ■  I- 1 1 -•.s.,-  ill  1 1: 1 1 1  -  j  i  ■  ■  -  at 

1  Al  I  heeailCII  I  rnW  oJ  ei|!cll<iiiurr.  %  Ill'll  dw  V  r  |!.T  4m  i  II. ; 
oul? 

■  Whj.1  suryecdpacilY  dues  ihe  nuantfecluref  pcstes*? 

1  ta  ni  _iM-v.pi  1 1 >j >J  iii  iiii  till  l  >ii  reeukr i-d  Jnro  i  In-  laveulury 
rancruLsi  teem  jail  m li- 1 1 rtl l- d  far? 

I*i  _  1 1  ■.  r  nair  umenr  stscenu-  did  at>i  pi  ..vide  a  wiry  4»  teteii, 
lwlL-iJ'iEeliirprewni1hic>ilLLli>i'nid[i«ii14iiL-iapp>iri  w-irld  laiiK-d  la 
brace  tonic  (phone  L  M|  |h.  r  malls.  ,  n.i  |j  tes  i  la  jii  1 1 1 1 1 1 1 1 1  la- 
u iv ruble  dad  verify  fhhcrtl  Led  lnfarnu[loii.  Uur  termers  hip  Jos  [ 
L  - 1  nl  I  ■  J  l-  _i  l5  l-  lii  llie  Jal,m  iihuIJiiii  belay,  pen  rid  rd.  V^cipiiJis 
empdoynb-iiil  dec  Uhias  were  Imp  k  led. 


ps  r€  spon  &it:f  tor 
identifying  GCSS-AF  and  ACS  mfonnatkin 
integration  requirements  and  funding. 


exietsto  du lie  and  maintain 
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GCSS 

background 


Gi.  ri_-  ecu  :hi"  -.-I  ■  - ■ . .-.l  Ar  I:-:m.v 
n  ■n  l-:k-|MiLii:  l f I 1 1 .  In  !  i . 
fin-  Air  rurm  Mil  Li  il  I  >1 1 1 1 1 1  j 1 1 ■  I 

/ 1 1  I'll  1 " .  -ija  kiT.v-I  i  i-'iIlI  i  ji-:  Fui'-Il'-l'I 
Lahcniliiji  vrJLica.  Ii  11:1  cuie  rLir.  utdiTlL: 
IxUE -l.sil  u'l  SvilL  lli  .VL.-jl.TIIIAIiLlI'L.  I 

pui,imu.  iLrAii  :mv  Muni  fijfy-jrl  QioiiajaL 
l  CuiLaLuML-jJ  ii'ta,  ■:  uiLpj'Ei.  and 

lil-..:LvurE  lOtl  j  AjeLIllIli-:  ■!  .hui.  iI  ik  iIiIil.I 
k-.' uu.-.k  iiJLTiratir d'iliy  r-4-.iu-:jiLi  It  FlI 
fianf  ii.e.  I'.  i  in^>[.-  UEilililii. 

h  1  hM.  m  SM  WMruii^tf  OC3S-AP  k-  Ik: 

i.-i!-.rJ-.iil  v.ilL  •ii-.vlk-i.  f:  mi  Oil  '.‘I'i.l  i'I'Mh 
S. .  ulaj  ■  Of  IlcfiilM  iOHl:  l  Iii  Mji-.ii.  lit*  Aa 
;  :•  •  ..-ill  •,  wIjHi.- ..  .I  IL.- OCi  jl  Al:  jiyjni 

:'i-,p:i:.  i:f  i  L1.  :u  Ll.  ■ !  .  -> I ■. 1 1  -> 

l  uilii' t  (fc£C  i  Liluhiard.  Kvakuia  Lm-jp  i  fiftii. 

TLuikir  I'jiiv  I .■  ■  j-.- L- •  i uf .  uf  i.  viui.ji  •  i.I 

.ii'.  iii:  iLi-i  I/l.-  I-K  'i  Uj.  jul  II  l- Il.uI  i 
Al1.  TIie  iJ.  \SS-A  I  l'-jiiIi  jrL  v  :ei  l-Aii:-.'-.  iii 
OvLiiuiL*  l>M-  Hi  LulUieOJ  Mu-liu  Fu-Ii.n.1 
AralEtaa.  V>iui  ills  A'iiiL  ■:  in-.  fi  :v  ?-1iff  iA  isle. 
.LaniLiL-.-i!  :cr  "Lai  <rL  liiLLliinjI  |>:  (tjihul.  ilk- 
I  Iii-: fu I  ■-ii'IAf  Lil-  i'lb  Ficec  It  ".v Aj  iji  iu!  Ilf: 
I  kniy  ■:  1ikv  -.-f  SL.i:  liE-ljiljlf.‘i  :■  iiil  . l*llI k--i 
AF  II.  I  lb:  InuLliili  J  zii'elhieU  fie  -L'K  L!S-AF. 

la  Jaly  iWT,  Al:  II.  E^iiilEdiKlllhitJCLiS-AF 
L'pfjriliulbirC'mi iii.  a  p-lililJ  uITie-ei  limp  >•  ill 
Eiurt-fiuLlsuEid  i ■.! > i l : 1 1  iliiu.  10  ■ : L-  ill!  :n:l 


fU-  I  Viuvil  u  ji  I iJ ici  :i  :il.I  llw  £1C3£-aF 
rkrr-luf  I  LiillI:h;-.  hi]  iL  L  h- I  jiL  napualiibl  v. 
.lilli.-'ily  ,in  :.l  iiiuLLi^fj. 

■J riti ■  i E  pill  II-  CK  SS-AF.  Li  SOptaihr  L'T1?. 

I:KL‘  ihic^jckiud  : ■  i . I  -:nF.i  iJl.I  'jl  (.( 

StfO,  LitiUialiiii.  j!FSJ-j  Lib^icuJ  uft  iLttUtfM 

jr-jii.  jjiiI  :  likLL'iiij:  IIil.ii  !•/  miLbluri  . 1 1  . 1 

iii'.ki.ii.-  .  ly-JAiiii.  ai  :L\  puiui,  GCSS-AF 

i  lvji  1.  ■  :i  L-,iiLtpl  i:fl  -:i  ll:n  i 

ir'sifiM.  I  Ii-j  KLttJ  h  'liiliii-jljr-j  IJniai.-ii 
S KiOII  i  v  ai  LliLuI  lu  iki  l'j ■  p  liuI  u-^l  j  e  a 
-JLIIIULTEijI  L'ff  llli  -Ikdf.  lit!  .  IIL' 'JlfuillljjiUfl 
iar:ulniiliiiL-  ■.■■:iiuiMi-:|‘-:i:i,:ij[(-ui'.ij  lhiul'jI 
•'.<  ••!■••.■.!  lU^-j-jlkli  frAcu  Lfk. 

Ali|l  :-iliiu  "ii-'iili"  ;-f  ::  '.miaJ  Oi 
|njj.r: ■  i e-i  ■■:&>)■  J  hil-  _.  i  :'ii  All  Ficee  ■:  i 
chi.xili'i-:  uffli.LT  Iii  i  i  jIk--.  r|  ihau  nil 

jit  ,L--jlii ■'  i  lui  iie:ii:u  I':h  aid  uf 
]|l  i-j  :.ii:  :ii4  :-|.:-ki  i>.  Lii  :  kiluu.  v  iie  vrJ Li u- 
•■eii  JiMulup^:!  uJ  iiil  iI.imli!  -.'ill :■  -iu  llii1 
hlukbul  Ail  Fuee-e  li>,i. -.'jlJl 

NO  .iil'I:  icKuijeloM.  u  'jl  juAd  h 

..k:  L  s  T  -j  i  u  ■  a  -  f 1 1  l-.-  1 1  ■  •  i  e  1 1  =  l*-_  1 1  i  i  -j  i  i_-j  i  ~  n .  I  l 
snibuLui  wa*.  ukt-nuul  in  L'A'7  u  Ln  Iii:  ,i;ifl 
v'IijiIv:  fur  lliO  AL'llSllI'  iiilIl-:-:.! 
a^T-:iiaih:  lili  fur  AlL'il:  ilif-niniJ  iml  av.k'ji 
:l-.ii::  1.M  i  i.la.  in  l^i:  Euuidinil  i.-j 

pMEb  I:-  IIiliIl-:-:  I  In  •:  Lari  u  .  ll..-  Kfpu  lair:.: 
i*r'aid»lrtil 


LIUE^H  Liilfsil  aLpELT<i  uflEUilUl  lUflEEULlli. 


!No  single  organization  is  t lie  lead  agency  to 
i den tii>  eross-fu national  I'equireiiieiits, 
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Ci  J  U IV  1399,  I h<j  Air  F  orcc-  Chi ai 
h'lc  'riinar  Mil  cor  Man  ^iin'ijr*  E  oard 
|'€IOHB'l  ootahllbhod  ttiu  GRITT  td  . 
eOL>£l£p  J  flili't  plan  l  .-r  P jll  i.l  l'>4L-hLi 
rh l-  rc!| iilraman ts  and  slfata^  lor 
aehltvlnfl  a  iiror  p  andl  tutcMBlul 
GGB3-AF,  0  aelrarle  t'l.j  ni-j-;  *nd 
■_ I -i 1  r 0 1 1 1  ■_  earn  marc*  oirort. '  As  a  re*  Jh, 
Bia  GfGTT  oro ooscs  a  crass,*,!  to  Idenr  V 
li  combat  a  jp  sori  Lb  air  plon  wlfih  Iha 
authority.  rc-soonsib  :>■.  .me  resources 
to  dalhar  on  Inld^uldd  GC  E-E-AF  lh«l 
Mipporta  Agile  Combat  Support— dm 
'L  Le.iLi  il.il  a  la  man  I  of  1I»  Ep.pcc  llomry 
At  re space  Fo re*. 

In  Mjppoit  oT  ttil*  ufTort,  ttrfi  Bit  ITT: 

*  Dwalopod  a  proposal  on  how  to 
organize  one  proceed  io  de-ru  t 
GCSS-AF  raq  Jljremanbs,  nchlova 
prsccos  'ccri-;  iii-.  erih-4.  Mnd  and 
irvewri  £t'3-E-4F  and  Electronic 
E  u-5-ir  t-s-s^E  terror  ic  Commerce 
(EB.’EC't, 

■  ^ce'csscc  arqanRallonol  -ilrucke. 
locallan,  and  die 

■  Identilled  a  load  agency  in  :  wm  on 
GCSE-AF  Inta^ntion  letfvHIti 

*  Drafted  a  lead  apancy  charier 
an'lnlrq  responsibilities 

-  Developed  the-  du  slres-s  ca-s-e  to 
support  Ifea  fecamme  ridillons  In 
nls  repo1:. 

■  Cralttd  an  osctjco  in  require  merrs 
dec  ament  iCREi  ard  a  program 
mmagemen:  a  rtct>e  !F*h"  Di. 

T?m  ream  was  also  tasked  to  attain 
So:  'clary  ef  Rh-  Air  Forco!CS  AF  approval 
•yti  no  proposal 


■ 

s 

1 
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i  Illation 


pm^quirernents  lead  agency. 

*  No  single  acquisition  management  chs0t 

•  No  warfighter  confidence  in  information 


single  manager. 


Appendices  6-82 


522 


539 


e  A I  r  To  r  c  !Tn  u  s  t  lc-or|'ecl  these 

organizational  and  operat^orfal  deficiencies 

*  ■ 

to  achieve  a  strong  and  successful  GCi 
AF,  a  key  enabler  of  Agile  Combat  Suppoi 
for  Expeditionary  Aerospace  Force., 


tbm 
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What  liiit;  chingfidJ 

Ea|:u LNUIY  Ak  -Uk-iUL-4  F'jrtu 

T  L  kar-d-Jn  .war,  a-. r-,-.- r-J J i  F.’ki  _j  lV  An 

T.T-.l  V_-Ii4i  H  fTJjaBlfB.  'UJil.  JlrJ 

iinii  i-jdir  if-  r-r-.-i  iii>.  rifuLy  ii^iilyi 
ijil--fiJ  iLiva?ifi  If-rfda  If-:  j  I “  ■.■■n i lj~i  nilnanr 
■  f-.i  diiHu  Air  !■■[•-. fiM.  i  Ji',  J.iiiL-  m  rcqxjod  H 

irfl.'!  Xlfhtca  II  £»  '*■■■'  1 1  iXt  pil  LU|.-.I 

'iiLii  4  k.  dr.  M.  -J-.il!  imp  nrc-d  ifniji.i  411m 

^dtcduj  f->.  cra-Ar  i»  tiiii£  i.'  -irr  --.  tv.  i^d, 

lid.  .d'Z  klkj.  I  i'-Tl-I  pd±l)li  .‘Mr.  All  I  Uf-L  J IJ .' B  J~, 

r->» 

IlllMIIIIUliLill  T'.-lllll'i---"|-  r.ldlljpiLIIIL  -: 

R  adorn  Ad  (ITHHAi 

Hv  ITM1A.  dlliKiiYi  IS  AJ1I-1  I'lM.  Lilli 

lIi'Ili!  V-  kvil.'p  .T.blllil.  JlrJ  liUllll JJ-a  -1 L 

irukamidiMidl  a  ifinJ  Jd  lu^mL  lalinaiuii 
ai.-i.iL-.-jd!.  I”  al-.  1  a-^jj-L a  il  l  sduadd  «l  luau 
r-r--.LR.-L.-,  h-.[i-iL  it'L-nai  1a  1  il.  ■■  uii'-n  Il.-li.I-.-i:  . 
Tkd  (3:1  Ml  I  kj.-  uiaiul  uL  l-  iuc.  k-  jci 

TMtirMlAQp 

S'd r,  iL-.ldr-li'-l.ld.-  il.1  Ci  If-  lIlUl  rkCUIjMl  IT.  3 
r.-.inidk-.L.  -JjutHaiJ.  »r-'  uLbrum  aai  n.  aat-.id 
Wa  .ttl  |  a  -  i  if-  Il.li.'l  Jr.  c-pa  m  i'h  oJ  ailii) 

iki-  f  j-  Jhn I i pcHitiL  Ai  dr  uni  lira,  ny  in  rr-v 
Ij-.ll  *j  Ji  .1  nan  *t.  -  -I  h.-.ii  ■.  I.  |.Il al  fl’i jILlIi.v .-.  u 
f-jjia.-j.jj  t.I.-faLdii-r  j-vdij..-. 

■S-ft-Hl  Dttrtkh|k*gniiL,  Modi  liny  iM 

'i-aiiuld.*  'Jii.  unJ  E.<:|ju-i--dlilHlk>- 

■- fir. J  iLf cdljpaaai.  iifikliap.  jri  j  tj(jji.-b.  jvI 
dif-dnxf cijnfdi  rxti  ji  itf  "fiti  l.cx.lji.  i u;  1 1*4 fa 
fXff  l-lV.'il  1  JI  I  1  EilllftJTM  JBI  dlf-pBiBBI  lldkd 
aiv.-jiau J  vi  1  k  ariiL'i  ft-uipicfi  1  rz-  - 1 1  a jj  1  - 
iLfl  i.-li'-.a:  h-'|  dr-taliap  -jb  i.-  iJaaiilV  jb>I  f.-irafi 

Ml=JEfH  Eli:  V-  IIlI-II*-  ‘-llflv  IL-.I  j  -JJ  1 1 .-  I  -JI  1--  ■ 
f Id'll 4.  auaiDETJUli  Jlf.  -4-4IJ  ik'.ij-f-.TLBI  lUJHd 
Lj.-lLlJ  -JLdl:  L-iB--VrjJK-Bjll-.LUlLBr.ld 

ElMHUIIIp  d.-'J  Pu-hL>-  --dl  fil'dllll-flr 

Vi\  m  B.'A  Lr. l*J  V  ik  .TjJapla  rTi'CTpdBI  IIlIrL-  l  r J 
Ll  .  i.lk,  BBpdndflf  d  I BY  i  .- .  13d  I-.IlBIi.  T.  IJ|L> /I  J-i  a 

cl.i  .j  .  i  ■  I ...  lhe  IXWniMI'C!  L-l-  ib.-'-.j-l-J  rrt  hbji 


llal  V.f,J  J--  IdL  Kid  fcjLi'-l  J  p ;.  -ji-  if -l  I  Jj.  B  r.-J-.  lilr.Yi  -J'j 
.liJ  lII-.-.-_’i  a  I ;  arlfl-]  iBpiinnp  aciicnu  .iiJ 

II  r.Tf  BlJ  Up  I  J.  .■-.-.Tf-'.L  1  BCJf:U 


Wliilu  ImjeSi  I  III1  N^tl1  l.ir>  and 
t  hi  i-f  iii'  SLu  ft  nJ  (lit*  Air  U;n  ivl1 
baif  dated  tiCSS-Af  h-  a  ki yy 
A(  S  ■l-ijilI'Ii.t.  cri.Li?al  In  E.\l 
YLfLUKHii,  [Jit*  Air  I1' ihr-u L!  h  .is 
ii'JrlK-r  a  il ;i hk1.  uaiU ic-il  lisunk 

ui  GCSS-Af  nor  a  cbamjki-un 

[|>  il  ll 1  Uh.  il  I  L'  [Jlv  i  iklMIlL 


Limiting  FucL-ii-is 

A  idaatfr  Mai  111  l  ijlK-i-.  f-r-iff u  1  k a  All  Kf-:-.-f- 
aaiai  1  l  a  I  ■  1  a  j  re.'ap  jjrJ  jjkkmjIbI  IK'-IH-AI  Le- 

-.liL.-J'.Bli  .-Lff-41  ikdAu  hKf-.fllK- 13*1  J.’lfl 

Mu  COS  E-Ar  U-  t  uJ  UUn 

Vildk  h-t-i  ill  r-.-.idji|  jt f  C‘-Lil  -al  K-jIi  -.-I  iLl  .iir 
T-.4*f d  hiri'-a.-jJuJdlLT-S-.J.r  A(TS  lb i-ldc  -.iu.-  J 

I.-  J.M"  UHH.td  .'JI  rjK»lilL33l£HrjiUblL  iddlr.L 

Mdi.-r,  f-L  ITCMS-AJ  aff  j  -.d Lixf-i-jn  ij  a L\ - a l  iLf 

Mu  =lu4.  1  nimiilt  Ll-jU  A||l  -ujf 

I  LTja.il  I  Ur  1 1 1-|  LiJ-)'  .Jl|.-4r3-J  I3lf43jjlf41  jLjpiianj. 
dBppSPi  f fO/lJI  ffirjDIII  .l'i J  IdBJfy  hj-_*ia-.- 
pilflKH  Ill-FiTY E.  U-  -4k  ■d.,JJ'4i  :--.1Ud,-  .T.  fl.'al- 
1Brlr-  Lj  f.'Bi'?.d  -J Cf- 4.  I B 1 1 4 1  ■  J Ji4  iLjBi'-.IhLBL-  .  I 

f4- -.L a.-  nprjJhlB  JVl  JBpTf-VfDEII  irjILlll  dr. 

II  jfikiii4>  Ef-  -jzpaaif  jv.--.-i  adi  f^ann.  iiidpruiJE. 
I-.lUIl  I -.BL-.  LV.  dak  tv  f .  If  .'IBK  f4Vf  BrX  I  U  -,L-4i  J 
pnfild  JNIEk  IBI  B.-I  Ji  lBr.lr-  L J  b-,.-KIB  .'  ^-JNI  IIl- 
■  ji k li  l'i  j'i  -.T-.-.-a-larjiL-M  j  irjdpiaLfa  SH!y,  il.m'.l 

LL-ldllf  I.IK  Illlf  iBLL  „'lI  l.ll.J  If  >[..-.  Bl  Jlll-B 

rf fp LT-JI BIC1B  I  K-.-.l-f-.Trld J  -.1IL1J  Ihf Lf-LBfslllj  If 
A 1 1  ■ JJ  B-.1  Ilf  iar.ll.ljl  rffUldfldUfl  f  Ef 1  BIIBd  ill 
lIcy-c Iff-aiL u  fc  Adpaiaia.  ill  iKk'J.'.iI  jjitsiBa.  A-.  a 


JH 
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QCEE-AF  '..'r-.i.'inll.'icrx  ATM]  H  ■_  I  1 1  ■!-  'lihii. . 


ik-LJi  i l  JtitT.  i iia 1 1  fl  it  tf-niai Kil  ac-a  naapmci 

ACS  1 1  ■  i  r-f'  ■  I,  1.  IJjlKEii  ISilJaiE  %Jrr--l!  ikt 

i  -::-t-J.ii.  i  an  AifMiKi  K- f-.t 

N  J  1 1  y  Iv  J^.*=  l|  U  i  ti-i  li-LI-fi  M  Jlhl^LIIIL--*  L  lldlll 

^ITS-AI'  jk-4iiMJr-r.  dii^dii  i-.  u  llIlJv.i  bjf 
biili  a  p-.aijii  im-.ir.i  ■  ■*■=  i i j ■  i  11  ■!  a  danpuia£ 
K'|J.riL'.'i  v'HiriJlJkl  : I d L- .  Jr.  Ail  Farid  J .■  C-,  I r 
I  rat  ■  ■  .-m.ul  tdk-vi:  id  Vdd  j  r  hcgicy  tc  il-.  .ui 
r-anca  i  W|jit--_-.-i  i  I ■  ■  s  iiirvxxxam^ 

IXSK-AJ.  Tjiai  X  l  jI  .■  !■  p-.  |.ijisi  1. 1  UrJx  itid 
KfCUIM  ,TJid.r.l  idd  III.IUl-  Jdl  Id1  i  lr-  BIillH 
M  Li-.-.yMi.  i ■  i  a  PCS !— A T  -rj  EMVicn  TjLfJar 
::obai  XT-  ^  I .  J 1 1  1 1--  Ai  a  iltit  -■ 

f.  hldl  J  ha  II  if  kl  ik  i.  L.  hll  '.LI+'  -f  Cilhpkl  ir.-JJ h.-.f 
K-  ■.\-.TJ i  if  ■  1 k  l  V  AJ  Jll.--id,jL.  IU  ibl^  ilfil  lil-. 

■  li'.  v.mu  ■ I  IlI  T-.'ilJ  ta  iiiv-L'.-.il  t-jai  f;  a  dL£ld 

■i^iarafli  ihaii. 

N  j  0,.il'i4lil‘:i  L-:iif  'Jl  iil':  ill  fcifthfsfriLiOli 
'au^iilh.il. 

Ui^tjh  lit  II  -.  MKUi  -.-i  rapr^ri  ■£  m  ii i a I v - 
h\irji,  :t  nuKkJ.  ltd  'j.ii  iiK;  .-llLl  jlitii  air.  a 

■  iiiuJ  mm.  iiiam-.'i  i  iii^'.'.r_vi  rian  aheiaim 

pivaiiddi  r.jjiL  m  .t  ieJ.  la  ill  virn  padaiUa- 
-Jlu'.az.-d.  Ill;  I  >.  ■  d  1 1  IE.  lulol  I  11-dfd  ->l  «  lilt 

I  .'iLiLu-.  q  -Mr  a.  Tf-aj  a  a  a  >■"  okcum  rimiJ 
K-  dUaiAl  --S  rfr  V  cL^TlEp  [WiltMl 


a I ■  i ■  1 1 1 i.a  j  asaap  .oil  jnniitlil  ECKi-A  J. 

■  przdailhf : 

-  It.imiKa  jjj  ai  dtJ  Jju. 

■  l>iliLd  lajn  -i  iti'j.  ia  ■iriit.'-ai'-ji  ri  if  ■' 
imda. 

■  L  .rki  itiajii-r,  fl  uJi  -L-ani;  tjpifliT.. 

HfrEEaEC  Sinyk  Ud-dHu- 

KIL  EC  -J-. -thl-t-  il  t  ■Hd'^aiiiNEJ  ludrdt 
pfn^a.  lvJ  iHUJtU  mu  inmraiir  it-.lj j-..- 
i  .*■  t.r.ti^i  bcdChiAt  bif  Ji  tlt>"_vih.-  naiijt  i  J 1 1  ■  as 

■  f ■  u t  -.-I  xi  fitXt .<iaif.  CmhE  .a?>.-“  ill.  iidir- . 
X|.-it 1 1 1 ■  t k 1 1 it*,  r IL  h.C  nil; .  nJ  :>.  It  >1  jpocv'J 
r.J«  MLcm-H  ia  Jr.i  iHsTUirwIa  EDS-Ar. 

j  I  f  T-3Y-X:  All  I'vIIl  Illif.T.  ai.Ml  ...hill  t  If  i'H  I  r3T  Ifi  X I 

ocur  J,-  ilk  tnr  h-.Uh|x.- 

i  uitiili  lit'-,  ii  ra  tii-iiliah.il  .-Lr  Z : i j-iai  » 
li  t  I  II  Kl  it  .l  ii -fita  f-.‘i>i-it!  ilY  natlii  -Villa 
Can t-a i  Majpxn  Ixkt  ■  KlU-l-AT.  ilai i  n  ic-  at  Jr.ju-J 
.Lr  I  .'ili  -spiuiihfl  v-  ik-.tl-  r-  ■  ■  J  f i J i ■  it.  Kll 
SC  pi-Jh.-f  ire  Il.iiiilTj.ii-  Hr.  i-.l  nrciir  l-.iritti 
lKV-S-AJ-  aid  BMC  k  k-  dc-H  itii  *ir  mi  mm  ■ 

r-Jltr..-  -Iifji  ft  l  r.  -.Jltahl|  lli-.i: 
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Re  cognize,  under  stand,  and  accept  one  GCS-S-AF 
vision  across  the  Air  Force 

■~Cre-atHiL-a-Miqt!jr&ment&  lead  agency. 

*  St  ream  I  me  GCSS-AF  a  pphos^io-B-and  integral!  on 

acquisition  management  -'-- 

*  Improve  warfighter  confidence  in  combat  support 
inform  atiom. 

*  Consolidate  EB,1 'EC  management  under  GCSS-AF. 

*  Develop  an-ct  u&e  key  measures  and  metrics. 
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the  w<ay  ahead 
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kMjynui.  -iMj-ji^ld-'2  Hd  Jod-iipl 

Mr  GO 3>-£jF  ribiuii  KKti  Ihr  Ai- 

Fl'IIJL  ElllL'  ULiJ  Ulill  Mill  I..’  ijlldl  i-1 

GCaSJtF. 

Tti  til  KK-AI  Y  J  r-T.  L-. -  ■  IH.'I  hk  tV.  ICjL 

dcuch  vut  iii  lI; .  u.'in,  jeJ  iitnt 
ALV  ni.  rii  ir- 1.  mil  iba  jrri- r>'  <1. 1 ■..■.!  -,-i  jcurr,. 

■  ll.U-J  I  Hr  Via  I  -imJiiii-.'iII'.  .Ur.vri£i  T !*■:■.  ii- 

ii'.tLL.-.  Vil  .'.I i  T.t.-j  .  i  h  r-.'apli .  LJ  hil 

vI-lIL'IIi  --i.uli.iJ1.  i-f-aiaLf-iri. 

Ihi  Aclufni  anil  if-  P-l  jMi  if^mniK'jii  iad 
ll?bL'.  J-.-lllNi  r.LjlI.-.  xrj  Jlr.lt  111.  Ill  dl.  i  LlJ 
mil  K  ll-.iI  if  Jiifi  .iid  iklu  l  Jr.  P-j  i  d  i  .- r-J f. .  Mr 
I'aJ-V  -■■  idjTTii  _'l  I  -  -J  I  ■  ■  I  ■ .  I  ■  1 1-- 1 1  li-ll'-J]  I  J  r-T-,- 1  r 
Iik--|  JL-Hi  ■I’j.-K I ■>-.  I  i>L- 1  "H  II  JIJM.  Ii  l-.jl  lllr. 

I  i'-r  aj  1.-J  i'-i  d  j].jaj.  I .'  J  j-_-  -.-■  a  l'i  a  iti'-rLil  (IL'Hi-AP 

■  ■I.  ii  1JJ1H1  no:  alir-  i :unn  nir  1 1  ■.  hi  £ l--  lJ 
mil  -.-I  ii  Fuaoi.  .-Lr  Fuji  laanr-cil  jjlJ,-.  uZ 
jaiiiiJei  a i  ill  In  1L1. 

A  ibaataifa  u  .v.-.ikil  i>  .rh  .-uk  ilr.  til  Hi -A  I 
i  L-i.  a  1  Ii  -.1  ai  ■ p i/.i  :tjlt  lean  ila  j r. ■  J  Iff  IICTK- 
AT  jJ  iil  i  l-jj a  j--.  uZiiaiViL 

L  itia'-a  1  ru-quidiaritiliLA  Il-j'J  d'juiiLj- 1-.-  luL  .  j 
tin  itftMVitfeilE  tflpptin  inlu-;  -riV;**  luEjui-uuiciilv 
u  T  I  In  wd  -  ll  1 1 1 1 1  l~  *  --auilid  |y  imphliiM  Hit: 
E.'.pjit!  UunA-y  Af  Uki: Jiu  Fuisd.  t?r*il*f=iiil 
nllh  JVjL>'  i.i  .Hid  Air  F-um-GIqUI 
Eii^ii^-j  iiiliiL 

■"-.-■■ri'-Ji  J  lai  lM.  i  jl  jni  r^-Eiifci  Jiitii  aaJ 
atiim  iha  If  ad  .inn1.  mlfc 

'  Iktali-p  n-rra--.il  .TJIJ+-.  1 1 L'  Hi  ■  J. P  v  Eliifciir 
jii  ::abji  uipr-i-ii  iiilir  bijii.t.  ■  a i l i. e  jii.t. 
n^aj-ini  n 

'  I  Jl  .Jl'.  .■J’jil  J  J-f  ri.-J-.i-i-  i  .>±-L'.ll-.  fli-L-- j- 
uir..qiaainni  i  iJ  _t.ji--‘i  aaiaai  ar  iii_-i  -.-I 
ar_-jin,a  -id'j.iL 

■■  F--.il:  aa i.  Jl.y-.-i.iii  jes  --iiiii.ir.-J  (IfKK-AP 
pi:pnai  l i lvl  aiaaMaJtn  i  r>  I  orr. 
r  L  jrjh-I  oipniKi  latZicp. 

*  I  .'.-iLiaa-f  ■  rJ  idLiiafL  jiiL  lv.  ,L- id  !h j:: 

+  nnrrCllZa-.a.riapahvi  la  JP1  pd  H-AC5 

— j - — 

+  Iljiar-  IU'L  12  II’  LI  1-UaiLl  IJJi’-T.  Ill -KJ 

I  .  ai  rtar.  t-rn.-a.-.  Ii-r  Uj*I  ip iai;  nan  %■ iluj. t 

r 

+  I  IlJIB  J  JeIl.’I  iLf.H  JI.J  1111  rfffCLJI  I.  ll  j. 

I  ha  p;  a  n*  •"■u-i  .-I  Fun  kv1  riiL  iil  t'?-.rjjr,-.'L-. 
+  L  iiik  J  Jiff:  ijf-nt'ii  iii.  '-. r-i-na^.-  if  AT-QCI 
+  I"  r  i  -r  /  ACTS  R  Cl 

P.f  1 1  ir-f  iii-ii  v  j«  i  i-a  K.-1  a  rc  J  l  if  - j'a  I  a  -.-I 

Jff.  rip:  -P_'il  III  lvl>d  .1.3 ri ■  E F  'JlLl  h'.l  lT  itf 

jipi.  rim.  jliIhii;  .  ri jj.'l-jNIi?,.  aid  iknniL. 

21 


P  'rii  -Jiih  ilia  AfJIKItf  jt  l.aaplrf  APS  ii. 

rfk-.lL-J  Jl  •dn  dl-lfnE  -  fH I .' ■  P L-.'J L Jr.  II 

'  UuiuiiliL  luiliaLKrdKiii. 

11  U  II  J  puihs  V-  VUV  1 1  r.  i4-.'.IIU  ■  fl  MlZj 
rjppjn  iLldL  II  n.'I  V-  tv.  ll  £ 

Iik  Jipiaia.  KartiiLarii,  ad  Ra.\aiEajif 
iKKi. 

i  111.  JiHU  l-.l  if  II  I  7l  jbJ  N  .VlV  itfriciaom. 

’  Flj.bf.L-  tv.  mpiRZ  I’  ''ii  ks  (1H3  jJ  l!-X 


I! ifu 1 1 ill i i;C  lb,'  ilil.i&Jti'  ul  [.uieln  iFB 
Vi:iii  t.'Ii  rl'.'-l  :ih  Mil  similize -aptnii. 


I  .■  jJ_- j!j  AtjlSOt  Jli^iii  nxr-tp-iti,  u  Lw.ni 

-.- 1 1.-  l  i ■  I'  1 1 ■ .  1 1  Mih  J  ll.  iIIliL  JlI  £-1  IJlLl  -t'l.'Ll'd  P-L 
-.l-.Jr.-d  Tlu  J  IlIII  i  --'lUJ iUI  - H i  i’4  I]  "f-  Id  I1I-.1K-  lJ 
ad  --.-.ViIIlj'  r  a  pi  l  JlI  i  ji  i  vil  mil  da  tiiJid  P-'|  i 
jpaaiial  i-:ii-.'-. j  .i-.i  j--j  lliijinri  Ksiifi-|tKI  FP.i  l 
IlMfPJE  Sr  ■  K’M-.ll1  uJ  S.TX 

TjifJi-r  jJ  -,-HKI  iIIIL-.l  V  II 

'  rx-jLlUl  Ui  CKliSvr.P  IIKf  MJKQ  llll-HE 

II  <’-.'i u.  I  la.iaHiil  Pljuu  pirfuai 

’  Ul  i  J "  J.r.llif  J|  :l-^  Ji'-.IIlIL-. 

’  FIj.1  jj-.  iiLlif.- --:  IlII.-,  j; -jiil- aLirjLij.r.L 
jiil  ziikniiiuHi 
+  tifwii^uaup^aiisH 

ill  h uni  iil’  QC33-AF  JppliCMitM  aid 

haM(] radon  irijahl'n  «un*t4m«iE. 

I  Pl  IICPlj-AP  >.ipl  .-  Jli-r  L.  liT  Itfil1.  bir-Xil  JiL-fH 
j  j_'i.j1l  j j. . j i-r.  i  ■j.Lf.-.iiLii  ipjia  iiipuPSf  Fir 
■jjuPi.ip  jII  1 1 !  j i  -Jirr-vi  jjpIilUIl-j  ad 

ia  Kijp  i  a  i  hi  a  h^jeiiibv.  I  .hsP-j:  riff---1  pri-jpnau. 

■  ■  B L-j-Jl  I Pjl  >.*bpLJJ Iff.  .i-|J.li  i'-ImHiIiUiI  V  Jl  IHJ  Ii- 

>l  lEJi^ianZ.  lata-  tlCSS-AP  v  1 1 1  -- ji  rodi£irj  il  -. 
Ik  fi>t-i-,  JJrd  .'■■.-'.jii.t.  a !  a  I  j :- 1  l  -dcf  Lpli  mni 
-dL-jntaiiJ  bh-.iui.-a. 

1 1 r.  - 1 r+-I-.  . r.'-j a i a  r>aa jpnaiLi  -.iiEa  v-.-ili 
-.  £i-.- jk'j.-iIi  IiLifu-.-a  i.  iiqurciaiiji  IulM  fcy  ifci 
iaaiihiajl  tjii  .jiil-  an  luiprana  rnurii hill 

liaJb-J  F|  dib  k Jl,  Jlir.-,.  H'r.  ?ilr-J.  «  Alia  MIIl-.IiI 

kiC  V"iL  mill  rlv.  I'PXl  !■!  jpaan  pipm  .kKih-J- 
«  -eol-jii  aiaijsiH  jnl  ^jauifaal  ■  i ■  1  r-r a ■  a i ■  .1 
: n Z.TJ  .JT-.  OIL 

A  CKTEt-JU'  5P0  aj-.idi.4E  -«P  1  Jl-J  iL-itriLf-df 

-IJliIIJiT.  ilJT-.-j--lk  T-'  Liliril-L-k'.J  .  f f -I  I  f.  d  I- -  Ll 

lead  r-i  - '  1  >k  f-aiiar.-.  ic  iar.L-_-.-aal  a r r-— ■-■- ■-_-.- a 
-db.-.lif-Lib  ji  irantg  ( K"S S-A I'  fiuplm  lah  j-  aid 
hanm 

Lr.1  a.ir.  i.lFW-AP  nL  Im  Afraid  ha  fii-.i.-j'i  B 
fiif mi  jal  at  IK1I>  irJ  li-m  11 jaru  pra^nat.  iti 
sacrairiaki.  uduha  j  j  1*1X1  -l-j-.iu-. 
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L-ruw  WArffeabir  Uf jyiirt  in  yAfiibiC 
b.  I  inl'uiiiidlk-- 

~ I ■  1  V  JIZ-jl  l-.l  1IIL-I  ti  Jill  T-3  Sill  .t'lJ  LJM 
J-.-.i I rJ-. I r. ■.  El  drl  lhli-111  JL-Hi  IU1-J  V-  lull  •  J-. -.  I- J  i-T J 
i  r-iiiiiL-.il  iiiik.-n.' jji-M  r-l  DJirnraal  j;  jiiiil. 
I-- J-.lLi.'  ATdi  Il|-  Llr.1  IJJi’-T.  .'I  [ICMS-AT.  L-  Juijr.il 
h  -  i  p i ■  _'ili-;iiaii.  r  |i_L_T|  ii  rd  v  j i  va 1 1 rr 
•Hindiifi 

Hi!  ClCKK-.M  i rj a i ii-ii  raaiarrvil 
.V.TIi.l  1-ii  JlOUlL  -LlL  II  -LlJ  4ria-  LfjfabKU 

,^F  I  iiliaaiiunca  JipyjJ  .-jpi>  i.jil  ■-.» i  il-ii 
Klcn±aihn.  Jja  ais^i^a,  jid:.<la-ti^J 
j-.-.'iT-.-..  i.li+-j|  .! n  J  mL  prvi  j,k  j  »tu  aaihwii  Ir-r 
LV.  JillLu  vl  !!ar.i|  J.'-.UJL.  lit  IVL  K ! I  IBI.  rii  lr-  i 
Hi  UjJ  .+ir,£,i  Ail  ii^mrija  11  a r. a  -naJ  lal  I'-T-C 
allrru  i*  J di  ali-a  3  r.  ir-i-uu  -i-lair-i  far  -jr-nr*  aad 
L'ja-  1 1 1 ii a|.  rriiKii  l jfr-i-1.  ill.  ii  ijir-a  la  trurn 
mil  iia  kiai  Tiiibuf  i.  Ai^mnia-Air  ISC 

■  •J  .iTliC  iaL-1  I.UIITH  k>  ,K>  J I  Hi  CK  ■  ■  -t  j  .  - 1  .J..I  i  j 
al  MVIH  JJUCbl  ±CjL  Dab-Ill  i.  MCLIli;  . 

l  li-iuUj  ii'j  EB'EC  in  iiiL-iii-jiii  undAr 

OC9B-AF. 

G'lil.  li  rva.-- -JiLui-J  Air  V 1 11  IX"  iraijiijir-. 

lllll  'j^l  ’l  J-.-Lj[l-  lll|.- Jlr:.-  i"  liL-.>.-Bi.i:-ili!|  Jill 

J li  r.-Vl '.  kjillti  hJ  -I-kl-.il  i:D  TX'  I B I Ill  ■  1. ■!  1 .  1.-. 
a-jLiL-,  MCHi-AT  .-I  -luaa 

Iti  !>■:  j|_i. a ,'|  mL  Djca  l.ll  IX"  |v-Ikl  j  rrn-.rL.-, 
LTfkiaitwJ  vuiai  ■  XV.S-.\r  j.vd  t&anly  j  rJ  j  J !  .-.\u-. 
i a i  ■  i ■  (.-  _-.-j  auic^i  j.vJ  r i ■  -i ■  -i ;  r-i-  l.ll  K1  jaii-n-nj 
Ihi  X- >n  vi  ua.'jH  jl  ff -hr.  lira,-.  i  ii-i  iii-Ui.  l.ll 
IX"  -TflLr  ni.  ii.ra  xj  li'-ul-ilii  mil  Lv.  i-.lIij.  i 
-Liiu-.L  f-r--.  UiJ  bj  C1£ZI,  ISC,  jbJ  itr  .t:  r«va 

I  .TlTJLi.-. JL--.V  AfiUL. 

liCHk-ll'  ad  Til  IX"  jrik|4L-  ivJ  nmi.  Sifv  lai  i 
Ii  _-iLrr  13  Vi  a  ieiiiu  \  i  -  Farri  >k-Jinun:c 
l‘;  i  iBIIk  niiiuL  Air  T;r-.--a  .Sir,  r:-.,ji.-  lies .  aai 
l3V|hLDBI  r.  --S  IXIlLm.  ilrllna  TVlU  AD  i  i.-Ui.  Ja.1. 
Ci  iak|.H  ia-1  air-  .ui  I'nvi  .■■■rku  Aiffm  pi:»ui, 
jar  i!  ji  al'dasnra  n-virrai’jiir-n  nrjir^.  iaJ 

■  r.-.uar.i  i  :4aa.-  ,1-l  -J-.Ml-f-.lL  . >j i  Kr-rr-i  i;n  fiCpdiqf 
mL  be  Javrdrf-d J  b;  Jr.  pi rf -r-a-. ■  I  iikiii  ■  M i ■■.-.■  ■  4  In' 
i.lTLS-AI  J3d  III  i:r  .'ih  Jku-Jir-k.  J  Jl  r-..-:-.i-il--il  ||. 
mil  -aaiJia  ai  ilr.  Hii.  ijrr,  aL.i  ill  l-.jil  .■  Jiar'i 
aipraHti  ir-  lv.  .U'SIRC 

Dlvl  'j|:  iimJ  wIA  hiy  muidlUrvA  ihd  nn'  iLV 
Im  vjUirn  Mil  Cl  E-SaF  -rlfyi  I. 

" l.r  -.--riKj.  -jff--n  -J-. njj.-n  r.  aiuaul  la  Jr.  drd 
-Li.-.v  C^um  I’rfumnu  iIatuivu  Far  41  CHS  alI 
bi  i  iij.  it-  Jr.  uriii.--.  ik-.-.lif-.ij.rj  r-r-.- J.-.  Taipiu 
atcauiia  lv.  rar-M-i  i  iiqacaaiaklrracnral^ 
ri.'i  kF.  ukcLiini  Ir-r  u  ■■  i  lUiir-  -J-.  njjr-r.  (IFS5 
aiamra  jk-  jli  a i  r-L'i  a  i-vn  uni,  jjir-jai  Ir-r  ilka 
i  r.l-.l  r.ll Jl  ik'-rk-RTiN  -.-I  iil  W1  aaj  It  L I'-tr L- J  UjL 
rvu-cla-.-a vi  ir-  rrllrri  aJ  Lia  ?kliar3i}  aiaiir 
lapui  Ian  btir.  r  jf-na-.  J  w  ill  ifJI  r-.r-.-n  aai.ilka 
i.lT;.S-.\T  iikl 1  Micia  ik'.ik-mrj  -I  i-Llr  I.-lj-.  r-r. 
pu rru  -.a i r  ~r-'-  ad  rr-ciac.  -r-Tr.  ab|A.im  r r.  Jd ■■_- 
-llI  l-  ,-l*aI  I+J-.I  ul-Jb  Jira  -,-r  BLiair.ii  rl  rjra 


RL'vMHiiirL-  uMinUhd.  m-»3  KMpl 

imA&CSS-AFVihkaCTI  jliuiv  iliu  Aif 
FlhWA.  EhibrAM  A*£  IriAlhLlUAIUlLlA 

ooa 4-jf. 


Ciddli  b  i-njuii'j— -inLa  I  Aid  iglAM^i  U 
r.->ruv  y ii  iHMHBAL-IUppAn  iiilu-:  ^i-.  - 
i  Liyii-uiib Ml  lliy  v. uil'  ghlui 
nAcdAd  CD  an  pJuAA*  1 1 L 
t.r^L  j  i.  .jiidiy  AirfDiin,  y.iiiiivlL  -T 

wiLh  -VjCn-j  And  AJr Fwi  Ck-un 

E-;dyuiiu-l. 


'=-1 1 ■_ 1 1 1 1 1 i 1 1 l  Ocas-Af  Ap^bcMrs*  Alid 
inly ai-Jli-ii  i-yMuikiliyii  MiiiidjLiiiyiil. 


liii|.'iy  vL  mi  li  jIiIli  y lmiIpJ-iiil'l  i* 

f  naif  ir  *uppAn  IntofmuUAn. 


L'l.'iijyliJii.y  E  B  EC  Ini-  iuimAhl 
undAT  CC’S':--^F. 


□  A-rAkf-  mA  IHI  LAf  AbaflkUl  lv  dud 
mMriXA  Fu  vuji.jiii  IBA  GCS'B-AF 
ulluil- 


Th© 
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The  case  for  GCSS-AF  is 

,  GCSS- 

AF  in  an  essential  enabler  for 
ACS — a  key  to  EAF  success. 
Initial  rat  urn-oil- in  vestment 
analysis  suggests  only  small 
quantifiable  financial  savings 
might  be  achieved  across  combat 
support.  However,  GCSS-AF 
brings 

essential  to  meet  the  needs  of  the 
.  These  would  be  more 
difficult,  if  not  impossible,  to 
achieve  without  GCSS-AF. 
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i  roi #  e  G  RI'  i  r  Senior  Advisory  Groi  up 

W  e  must  plan  and  execute  bur  deplcymunl  auiivilies  faster  and  hiqh 
accurately  linn  wu  do  today  if  WS’re  1c-  c-ffuclivuly  put  bombs  din  target 
within  4-0  I  nuns.  Cur  i  u  ill  pi  urmi  ug  processes  do-  nut  adequately  support 
employment  ol  the  E^pc'dilic-nary  Ac-iuspucu  rorcu's  lEAl")  primal y  rbiffie 
element,  lilt1  Air  Expeditionary  Fbrtee  |.AE  T  | .  We  need  Lc-ols  Lu  a  u  ppurt 
rapid  ACT  u  mpluyniuiiL  with  liflducud  deployment  footprint.  This  Will 
enable  us  L*  tarry  more  eecth  to  the  IflgM  and,  thus.  increase  0  u i  (oofi?- 
iivtaflriitlci. 

All  hough  ijui  farces  and  a- lip  pod.  uleimienls  perform  u  d  Superbly  in 
KbSOVO,  we  pel i u d  tQ*  mu  eh  bin  brute  ferci,  lung  hbuifs  uver  the 
telephone,  and  c-ui  high-quality  people.  As  Wo  become  leaner  and  face 
new  and  difTereM  Challenges.,  wu  ni  us!  aclfli  uve  new  levels  c  f  integrated 
capability.  We  need  Id-  effectively  employ  new  tech  uu  lug  it's  being 
exploited  today  in  the  Commercial  seClc-r— such  as  smait  e  a  i  ds;  web* 
bruWSi r*enatiied  business  processes  proviJ  ing  real -lini u  updates  bf 
SUppbd  slulus.  fium  ammunition  balances  lb  individual  Shot,  recuid 
statuses:  and  integrated  views  cf  information  acro-ss  our  functional 
cuiiini u ii ities — to  hue  our  perfsuhhel  Id  cany  thru  tight  Id  cur  adverser ies 
rather  Hi  an  staff  phone  banks  1c  coll  net  suppe  i  L  status. 

GCSS-AF,  as  a  system  bf  systems,  is  the  principal  Ic-c  I  that  Wilt  deliver 
Agile  Combat  Support  Id  the  A  EX’.  IF  the  Air  Force  is  to  achieve  the  EAF 
vision.  Linen  the  leadership  must  Stand  strong  behind  thu  GCSS-AI" 
program,  focus  Lhe  functional  corn  inun  ities  c-n  the  milasiUn  val  u  u .  and 
effectively  implement  the  ifecom  rnendalions  bf  the  GRITT. 


Gordon  E'.  f  orhell 
Dayton  Aerc-s  pace.  Inc 


L-v1*  'i  -r.i  ■ _ 

Harold  Vi'.  Sa-i  ens-c-ii 
The  MITRE  Co  ppm  Mi  oil 


Software  Enginec-iing  IrisLitutu  Independent  Consultant 
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Appendix  61 

GCSS  Capstone  Test  and  Evaluation  Master  Plan  (TEMP) 

(See  PDF  File) 
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Appendix  6J 
DODIIS  Test  Process 


Explanation  of  Department  of  Defense  Intelligence  Information  System  (DODIIS) 
test  process: 

The  DODIIS  test  process  is  an  iterative  process  that  follows  the  software  item  through  its  life 
cycle  and  assesses  items  continuous  improvement  towards  meeting  installation  and  integration 
requirements.  The  DODIIS  testing  team  evaluates  the  testing  requirements  for  each  new 
software  release  early  in  the  development  cycle.  The  DODIIS  development  and  testing  process 
is  detailed  in  the  DODIIS  Instructions  document,  which  relates  the  process  to  DoDD  5000  series 
acquisition  milestones. 

DODIIS  software  products  strive  for  one  major  release  and  one  minor  release  yearly.  Major 
releases  generally  add  new  functionality  or  interfaces  or  make  other  large  scale  changes  to  the 
software.  Minor  releases  upgrade  COTS  or  GOTS  components  and/or  provide  limited 
enhancements.  Software  “patches”  are  generally  minor  changes  to  provide  corrections  in 
response  to  user  software  problem  reports  and  do  not  have  to  be  tested  under  the  DODIIS 
process. 

The  development  program  office  is  responsible  for  certifying  Factory  Acceptance  Testing  (FAT) 
has  occurred  and  all  documentation  and  other  deliverables  are  acceptable.  The  FAT  often 
involves  a  sampling  of  operational  users. 

The  Joint  Test  Planning  Meeting  (JTPM)  brings  together  all  players  (integration  testers,  security 
certifiers,  interoperability  testers  (JITC))  to  plan  specific  testing  activities  for  a  new  software 
release  as  well  as  the  resource  requirements. 

During  Beta  I  testing  the  item  is  brought  into  an  independent  Government  facility  and  turned 
over  to  the  DODIIS  testers.  DODIIS  testers  check  the  ability  to  install  and  integrate  the  software 
into  the  DODIIS  infrastructure  (i.e.,  integration  with  COE  environment).  Security  certification 
generally  occurs  at  the  Beta  I  test. 

Beta  II  testing  is  typically  conducted  at  an  operational  site.  The  JITC  generally  conducts 
interoperability  testing  (testing  of  interfaces  for  passing  data  between  systems)  at  the  Beta  II  site 
unless  the  interfaces  and  data  are  available  at  the  Beta  I  government  facility. 

Training  certification  occurs  in  parallel  to  this  process  by  the  cognizant  training  organization. 

The  results  of  FAT,  Beta  I  and  Beta  II  tests  are  collated  within  5  business  days  and  attached  to  an 
Acquisition  Decision  Memorandum  (ADM)  prepared  by  the  SPO.  Specific  recommendations 
are  made  relative  to  deploy/fix  before  deployment/fix  and  retest.  The  ADM  is  submitted  the 
DODIIS  Management  Board  (DMB).  DMB  is  chaired  by  DIA  and  consists  of  voting  members 
from  each  Service,  the  Unified  Commands  and  other  DoD  IC  Combat  Support  Agencies  (NSA, 
NIMA,  NRO).  DMB  makes  a  decision  relative  to  deployment  or  other  action. 
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DODIIS  relative  to  OT&E: 


There  is  NO  conflict  at  all  with  AFOTEC  or  any  OT&E  organization.  The  DODIIS  testing  does 
not  replace,  and  in  some  cases  has  been  done  in  coordination  with  formal  OT&E  conducted  by 
the  various  responsible  service  organizations.  Joint  Collection  Management  Tool  (JCMT)  is  an 
example.  AFOTEC  came  to  the  JITF  to  prepare  for  an  OT&E  they  were  going  to  be  conducting 
at  an  operational  site,  and  participated  in  the  Y2K ISR  testing  done  here  last  year. 

It  has  been  noted  that  better  communication  and  coordination  with  the  various  service  OT&E 
orgs  needs  to  be  developed.  INSCOM  has  participated  in  the  DODIIS  Test  Study  (ARMY 
OT&E).  The  DODIIS  Test  Study  is  the  need  to  involve  ALL  testers  throughout  the  software 
lifecycle.  DODIIS  has  the  Air  Force  and  Army  directives  and  regulations  on  testing,  which 
mesh  very  well  with  how  DODIIS  does/”plans  to  do”  business. 
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